我使用ZMQ設計了一個pub/sub架構。我需要最大的可靠性和可擴展性，並且在所提供的各種可能性中迷失了方向。ZMQ pub/sub可靠/可擴展設計
目前，我收到了一個由經紀人鏈接的發佈者和訂閱者。代理是一個簡單的轉發器設備，爲發佈者提供前端，爲訂閱者提供後端。
我需要處理代理程序崩潰或斷開連接時的情況，並提高整體可伸縮性。
好了，所以我想添加多個經紀人，出版商將循環賽的經紀人將消息發送到，而用戶只想訂閱所有這些代理。
然後，我需要一種方法來獲取可能的經紀人的名單，所以我寫了一個名字服務，提供按需代理的列表。發佈者和訂閱者詢問哪些經紀人要連接到這個服務。
我還寫了一種「懶海盜」的（即嘗試/重試一前一後）的情況下，可靠的名稱服務的主名稱服務下降。
我開始想，我設計它錯誤的，因爲代碼庫是不停止的規模和複雜性增加。我迷失在ZMQ提供的各種可能性的叢林中。
也許路由器/經銷商的基礎可以在這裏使用？
任何建議非常感謝！
這是不可能的，因爲它是在這麼多的假設，其中許多可能是錯誤的前提，直接回答你的問題。
由於使用了錯誤的方法，你會迷路。將0MQ看作是一種語言，你還不十分清楚。如果你試圖寫出「最大的可靠性和可擴展性」，那麼你最終會得到哥斯拉的嘔吐物。
所以：使用我在指南中使用的方法。從核心消息流的最小解決方案開始，並使其正常工作。仔細想想要使用的插座的種類。然後進行漸進式改進，每次完全測試以確保您瞭解實際發生的情況。定期重構代碼，因爲您發現它越來越多。繼續，直到你有一個穩定的最低版本1.不要在開始時瞄準「最大」的任何東西。
最後，當你已經理解了問題的更好，再從頭開始，再次，建立在幾個步驟的工作模式。
重複，直到你完全主宰了這個問題，並學會了解決問題的最佳方法。
這似乎是最複雜的，從試圖使代理服務堅持一個失敗的情況下造成的。在應用程序級別解決這個問題可以提供最大程度的靈活性，但如果您從頭開始，則需要最大的努力。
而不是在應用程序級別處理此問題，您可以改爲在網絡級別處理此問題。像處理任何其他簡單的網絡服務一樣對待您的代理，並在主服務器不可用時使用IP故障切換機制（例如，起搏器/ corosync，UCARP等）將虛擬IP地址故障轉移到輔助服務。
這極大地簡化了您的發佈商和訂閱者，因爲您不需要名稱服務。他們只需要知道單個虛擬IP地址。 ZMQ將負責根據需要重新連接服務（即發生故障轉移時）。