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

本文通过一个具体场景探讨了ActiveMQ中的forwardingbridge机制。详细解释了多个ActiveMQ实例间如何通过转发桥接相互连接及消息传递的过程。特别关注了消费者客户端在不同状态下的消息接收情况,包括客户端断开连接后的消息处理机制。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

                                                                                                                        图一

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

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

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

Forwarding bridge是多个activeMQ的一起工作的一种工作方式,如图所示,A brokerB 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重现启动,并链接上client1client2,发现没有任何消息可以给它们消费,但其实B上还有没被client3消费的消息。

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

       场景2描述:

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值