有關高可用性的酒吧/子結構的建議

Question

這似乎是一個相當普遍的問題，但我無法找到答案。假設我有一個發佈/訂閱基礎架構，並且解決方案的一個組件必須在接收有關該主題的消息時採取行動（每個消息只應執行一次操作）。組件的高可用性以及用於負載平衡的主動 - 主動語義也很重要。

使用P2P消息傳遞模式，通過運行消費者的多個實例監聽同一隊列，可以很容易地實現此目的。但是，對於pub/sub，消費者的每個實例都將收到自己的消息副本，因此可能會多次執行相同的操作。

我想要的方法是讓分離的組件以主動 - 被動模式運行，並通過將消息轉發到隊列（它可能是另一個代理甚至像Redis之類的東西）將pub/sub轉換爲P2P。翻譯者的兩個實例之間會有一個心跳消息，一旦主動實例因任何原因斷開連接，該消息將允許被動實例訂閱主題。

另一種選擇是在所有活動實例之間共享存儲，並且一旦一個實例開始處理消息，它將在存儲器中指示這一點，因此其他實例只會從處理中刪除消息。我擔心這會導致很多爭用問題，從而將主動 - 主動配置的好處歸結爲無。

我正在尋找其他方法的建議，或者對我列出的方法進行改進。

Answer 1

有點不清楚你的製片人（pub/sub）有什麼擔保。它可以支持持久訂閱嗎？

對於您的可用性要求，第一種解決方案可能更可行。實施領導人選舉協議是一個非常難以解決的問題。我建議使用像Zookeeper這樣的現有解決方案。無論你如何選擇這樣做，你至少需要3名成員參加領導人選舉。例如。 3個Zookeeper節點。

數據庫鎖定選項將導致您的延遲，並再次滿足您在設置羣集時需要的可用性要求。