因此，您希望跨分布式主題使用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

總結

以上是生活随笔為你收集整理的ActiveMQ群集，持久订阅者和虚拟主题可助您一臂之力的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。