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那里搶救出來。

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

activemq 持久訂閱

總結

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

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