以前对JMS尤其是activeMQ不了解,一看到什么地方需要使用消息中间件,就比较反感。主要原因是感觉JMS的实现都比较复杂,怕在真实使用过程中出现什么问题时会比较被动。所以,我们基本上是自己写类似的消息中间件,当然功能非常简单。但其实我们自己写出来的中间件,随着功能的不断增加、人员和时间的种种问题,导致最终我们自己做出来的所谓消息中间件越来越不能维护。在吸取了一次一次这种重复发明"轮子"的事情中,我们觉得也许一开始就采用成熟开源的产品也许是条更好的方式。
感觉到现在或将来我们对JMS的使用会更加深入,为了适应这种的需要,作为软件研发人员,需要对在我们工作中占有重要地位的开源产品有源代码级别的熟悉,尤其对我们这些英语不太好的,因为目前用的多的开源产品基本上是以英语作为基础的,那么我们想要提交一个bug或讨论一个什么用法的时候,就比较被动,而且眼巴巴的等着其他人来解决,自己一点都
使不上劲的感觉真的很不舒服。
我们选择activeMQ来分析它的核心架构、源代码,就是希望能尽量少的发生上面的情况,尤其在我们分析activeMQ的过程中,发现其源代码中确实存在不少小问题。消息中间件在许多项目或产品中占有非常重要的地位,虽然我们目前还不是activeMQ的代码提交人员,但希望通过对activeMQ的源码分析这种方式,同样为使用activeMQ的同行们提供一点帮助,也算是间接为开源做点事情。
在后面的一系列文章中,我们将主要从如下几个方面来分析:
一、activeMQ的核心线程的功能和生命周期
二、消息存储的kaha实现的分析
三、消息队列(Queue)实现的分析
四、activeMQ的领域模型
五、activeMQ中TCP通讯机制
六、activeMQ的Cluster
七、activeMQ中内存使用和管理
作为开篇,首先我们非常尊重activeMQ的所有committer,它是个不错的软件作品,我们的分析是基于5.1版本的代码,就象任何事情一样,尤其是软件产品它的成熟是需要较长时间的过程,我们也会把分析中发现的5.1版本的bug于大家分享,下面我就以一个小bug作为整个activeMQ分析的开篇。
为了表述的方便,我们把这个bug叫做bug_1,为了讲清楚该bug,首先我会把相关的背景做一个介绍:
消息指针(Message cursor)是activeMQ里一个非常重要的核心类,它是提供某种优化消息存储的方法。消息中间件的实现一般都是当消息消费者准备好消费消息的时候,它会从持久化
存储中一批一批的读取消息,并发送给消费者。消息指针维护着下一批待读取消息的相关位置信息。
消息指针在对不同的消息消费者时,它的内部处理机制也不一样:
1.当消费者跟得上消息生产者的时候,是快消费者。那这种时候Message cursor的内部过程如下图所示:
2.当消费者慢于消息生产者的时候,是慢消费者。那这种时候Message cursor的内部过程如下图所示:
上面两种情况是能自动调整的,当一个消费者从快变成慢或从慢变成快的时候,Message cursor应该做自动的调整,在5.1里面这种自动调整有点小bug,它只能从快变成慢,反之则不行。具体bug原因应该是疏忽写错了,代码在类AbstractStoreCursor中的public final synchronized void remove()方法中的if (size==0 && isStarted() && cacheEnabled)这一行,只用把cacheEnabled改为useCache就可以了。(该bug已经被后续版本所修复)
我们非常愿意能推动activeMQ的使用,并希望能够结合activeMQ做一些相关的辅助工作。所以如果大家在实际工作中碰到使用activeMQ的各种问题,如群集,消息重发等等,都可以告诉我们,大家一起交流,同时我们也会在线下召开一些交流activeMQ使用和研究的聚会,我们的联系方式:email: yunweitec@yahoo.cn qq号码:ActiveMQ研究群 62835781
原文链接:http://blog.csdn.net/kongqz/article/details/4014788