activemq 持久订阅
因此,您希望使用ActiveMQ跨分布式主题进行发布-订阅,并且要可靠。 您可以使用永久订阅,对吗? 可以,但是,如果您将群集与ActiveMQ一起使用,则可能会遇到意外的行为。 我最近在一个客户端上,我注意到了这一行为,并且还注意到在使用Weblogic JMS集群时也存在相同的行为。 那么问题是什么,ActiveMQ可以解决什么问题呢? 好吧,我假设您已经读过标题,所以您可能有个主意……但我还是会继续前进……
考虑这种情况。 您有经纪人A和经纪人B。它们在两个方向上都联网在一起,形成一个完全网格类型的经纪人网络 。 又名,群集。 然后,您将使用故障转移URL failvoer:(tcp://hostA,tcp://hostB)
拥有一个订户FOO。 这意味着订阅者将从故障转移传输中的节点列表中随机选择一个URL,然后连接到该代理。 到目前为止,一切都很好。 假设故障转移URL选择了要连接的代理B,并且订阅者在代理B上创建了对主题TEST.TOPIC
的持久订阅。在TEST.TOPIC
,代理网络将确定B上有一个新的TEST.TOPIC
。因此,如果经纪人A上有任何生产者,那么经纪人A应该将消息转发给经纪人B(消费者在哪里)。
现在让我们说订户FOO决定断开与代理B的连接。这是很好的,因为这是持久预订,因此消息应保留,并且如果订户FOO返回,则它应该能够检索传递到主题TEST.TOPIC
任何消息。 TEST.TOPIC
不在时。 但是,如果订户FOO使用故障转移传输直接连接到代理A,会发生什么? 最终将创建一个新的持久订阅(它不会使用与网络创建的持久订阅相同的..,因为该用户与网桥相关联),但是它将无法访问代理中可能存在的任何消息B.当制片人发送更多的消息给A,它也将尝试着给经纪人B的是在那里用户原是 。 现在想象一下可以连接,断开连接并重新连接到集群中不同代理的多个订户。 您最终将因订阅泄漏而到处丢失消息。 uck 这同样适用于真实的故障情况,在这种情况下,订户FOO不会自愿断开连接,而是代理B崩溃,而订户FOO被迫重新连接到代理A。您仍然会丢失消息。
好吧,事实证明,这种行为在具有分布式主题的Weblogic服务器和集群JMS服务器上也存在(大致相当于我上面描述的代理网络)。 那么,我们将不能可靠地进行分布式发布订阅吗? 好吧,我不确定WLS如何解决它,但是ActiveMQ有一个很棒的解决方案叫做Virtual Topics 。 对于分布式pup-sub来说,这是一个很棒的功能,但即使在单代理部署中,它也克服了持久订阅者的限制。
有什么限制?
考虑这一点…您正在使用主题TEST.TOPIC.
的持久订阅者TEST.TOPIC.
事实证明,对消息的处理要花很长时间,因此您希望让另一个订户在同一消息通道上侦听以“平衡”工作负载。 试试吧。 您会很快发现JMS规范不允许这样做,因为持久订阅者必须具有唯一的clientId
和durableName
并且不能有多个订阅者在侦听相同的消息流。
那么,您如何在池化连接的应用程序服务器中部署订户。 您正在尝试在多个持久订户之间共享连接。 好了,您将再次遇到持久订阅者clientId和持久名称的限制。
因此,回到我们的分布式发布订阅问题。 如果使用虚拟主题,则可以解决我上面描述的问题。 虚拟主题在幕后使用队列(对于消费者来说……请阅读虚拟主题上的Apache文档,它有一些很棒的示例),使用队列,您可以将消息重播给您(例如,当订户重新连接到A时,它是消息不会丢失,因为可以重播消息),或者如果B代理由于某种原因而发生故障(失败),则可以让一个从属服务器在其位置等待重播否则可能丢失的消息。 有关更多详细信息,请查看有关具有持久订阅者的分布式主题的ActiveMQ常见问题解答,因为我现在就开始编写它。
参考: ActiveMQ群集,持久订阅者和虚拟主题,可从Christian Posta Software博客的JCG合作伙伴 Christian Posta那里抢救出来。
activemq 持久订阅