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

                                                                                                                        图一

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

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

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

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

首先描述forwarding的初始化过程，A broker启动的时候，会主动寻找B broker，直到和B broker建立链接，B会在和A建立链接的过程中把它的一些重要参数告诉A，其中最重要的就是B保持的消息消费者列表，它会送给A，当A收到这些消费者列表后，会把它们当成自己的消费者一样对待，没有区别。这之后消息消费者就可以消费A收到的消息。

场景1描述：

client3链接在B broker上，当client3关闭后，A还是会向B发送符合要求的消息。这就导致，如果B停止，A重现启动，并链接上client1、client2，发现没有任何消息可以给它们消费，但其实B上还有没被client3消费的消息。

             场景分析：开始我们还认为这是5.1版本的一个bug，但在研究代码后，发现它是这么处理的，关键代码是如果client3是持久的或其目的是个Queue，并且该Queue不是临时的，activeMQ就把该消息消费者的consumerId给替换了，用新的代替。这样之后，当client3关闭后，B向A发送删除消费者的命令，但此命令中的consumerId是client3原来的，A当然没法删除该消费者。这就导致client3关闭后，A还是会把符合要求的消息发送给B。我们认为activeMQ这么设计的用意在于，可能在于效率等方面的考虑。那么我们又引出了另外一个问题，那什么时候client3会真正从A broker中删除呢？答案是要么A停止，要不B停止。

       场景2描述：

              链路都正常，但是在C broker上的client4没法收到A上符合要求的消息，这时候，需要看看broker的networkTTL的设置，默认是1。