因此，您希望跨分布式主题使用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那里抢救出来。

翻译自: https://www.javacodegeeks.com/2013/02/activemq-clustering-durable-subscribers-and-virtual-topics-to-the-rescue.html