activeMQ的源码分析

activeMQ的源码分析－开篇

以前对JMS尤其是activeMQ不了解，一看到什么地方需要使用消息中间件，就比较反感。主要原因是感觉JMS的实现都比较复杂，怕在真实使用过程中出现什么问题时会比较被动。所以，我们基本上是自己写类似的消息中间件，当然功能非常简单。但其实我们自己写出来的中间件，随着功能的不断增加、人员和时间的种种问题，导致最终我们自己做出来的所谓消息中间件越来越不能维护。在吸取了一次一次这种重复发明"轮子"的事情中，我们觉得也许一开始就采用成熟开源的产品也许是条更好的方式。

感觉到现在或将来我们对JMS的使用会更加深入，为了适应这种的需要，作为软件研发人员，需要对在我们工作中占有重要地位的开源产品有源代码级别的熟悉，尤其对我们这些英语不太好的，因为目前用的多的开源产品基本上是以英语作为基础的，那么我们想要提交一个bug 或讨论一个什么用法的时候，就比较被动，而且眼巴巴的等着其他人来解决，自己一点都使不上劲的感觉真的很不舒服。

我们选择activeMQ来分析它的核心架构、源代码，就是希望能尽量少的发生上面的情况，尤其在我们分析activeMQ的过程中，发现其源代码中确实存在不少小问题。消息中间件在许多项目或产品中占有非常重要的地位，虽然我们目前还不是activeMQ的代码提交人员，但希望通过对activeMQ的源码分析这种方式，同样为使用activeMQ的同行们提供一点帮助，也算是间接为开源做点事情。

在后面的一系列文章中，我们将主要从如下几个方面来分析:

一、activeMQ的核心线程的功能和生命周期

二、消息存储的kaha实现的分析

三、消息队列(Queue)实现的分析

作为开篇，首先我们非常尊重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的自动发现功能让它们来发现彼此的存在。自动发现功能的好处在activeMQ里面，我想主要能使用在当目前的activeMQ集群处理能力不行的时候，可以动态加入新的activeMQ来分担负载，这就可以很好的水平扩展。

首先，我们对图一中的带颜色部分做一个说明，带颜色的小矩形都代表着能发送和接收广播数据包的通讯端口，有‘S’标志的表示该端口主要向外发送广播数据包，有‘R’表示该端口只接收广播数据包。具体自动发现过程描述如下：activeMQ通过端口向外广播它们自己，当某activeMQ收到一个广播包后，解析该广播包，并从中建立activeMQ之间的通讯桥梁。而当某客户端收到包含activeMQ的基本信息的广播包后，它也会把这个信息保存住，在需要进行重连接的时候进行重连接。

讲到activeMQ的自动发现功能，我们就不得不说到它的配置文件，具体内容如下：

1．如果想拥有向外发送广播信息的话，也就是图

中带‘S’的端口，修改配置文件中的< transportConnector

…/>，这个地方得加一个参

数discoveryUri="multicast://default"。

2．如果某activeMQ想能自动发现其他activeMQ，也就是图中带‘R’的端口，修改配置文件中的

…/>，这个地方uri要类似这样设

置uri="multicast://default"。

activeMQ在实现的时候也有点意思，我们所说的

带‘S’或带‘R’的端口，它们的功能都在同一个类中实现：MulticastDiscoveryAgent。而客户端的相关实现，则在FailoverTransport类中完成主要功能。

activeMQ指南针_forwarding bridge的实现机制、使用说明

图一

陆续有朋友和我们进行联系，很多朋友都提了不错的建议，但目前提出加入我们分析的人员不多，希望我们帮助的案例还不多，我就选择其中一个做为切入点，希望能帮到相关的朋友，同时也做为指南针计划的开篇。

问题描述：我们想通过forwarding bridge方式联起来多

个activeMQ(也就是Broker)，但是消息消费者client3接收不到消息。(因该朋友对问题的描述不够详细，我们暂且这么设定问题。希望以后各位提问题最好带上图一所示的消息拓扑图)。

下面我将结合图一所示的消息拓扑图，结合我们分析activeMQ 源码，来具体说一下forwarding bridge的工作方式和使用时应注意的地方。

Forwarding bridge是多个activeMQ的一起工作的一种工作方式，如图所示，A broker把B broker作为它的消息forward的下一站，我们也可以把它理解为消息转发。

首先描述forwarding的初始化过程，A broker启动的时候，会主