分佈式服務器實例之間的數據廣播

Question

我想在我的特定應用程序中獲得關於服務「名單」的建議的一些反饋。我有一個服務器應用程序來維護與客戶端的持久套接字連接。我想進一步開發服務器來支持分佈式實例。服務器「A」需要能夠將數據廣播到其他在線服務器實例。所有其他活動實例也一樣。

選項我試圖研究：

1. 的Redis /動物園管理員/道崎 - 每個服務器實例將其自身註冊到配置服務器，並且它改變了所有連接的服務器將獲得配置更新。然後怎樣呢？
   1. 維護與每個服務器實例的端到端連接並使用每個傳出數據遍歷列表？
   2. 一些自定義的UDP組播，但我需要推出自己增加的可靠性。
2. 自定義消息代理 - 每個服務器連接並通知它時運行和維護註冊表的服務。保持與每個服務器的連接以接受數據並將其重新廣播給其他服務器。
3. 一些可靠的UDP多播傳輸，其中每個服務器實例只是直接廣播，並且沒有維護名單。

這裏是我的顧慮：

• 我很想避免依賴於外部的應用程序，像動物園管理員或道崎，但我顯然會使用他們，如果它的最佳解決方案
• 通過自定義消息代理，我不希望它成爲吞吐量的瓶頸。這意味着我可能還必須能夠運行多個消息代理並在擴展時使用負載均衡器？
• 多播並不需要任何外部過程，如果我設法推出我自己的，但否則我需要也許使用ZMQ，這又使我處於依賴的情況。

我意識到我也在談論郵件傳遞，但它與我一起提供的解決方案攜手並進。 順便說一句，我的服務器是用Go編寫的。任何關於保持可伸縮性的最佳推薦方式的想法？

*的目標編輯*

什麼我真的問的是什麼，是落實在分佈式服務器實例之間廣播數據的最佳方式如下：

1. 每個服務器實例維護與其遠程客戶端的持續TCP套接字連接並在它們之間傳遞消息。
2. 消息需要能夠廣播到其他正在運行的實例，以便它們可以傳送到相關的客戶端連接。
3. 低延遲非常重要，因爲消息傳遞速度很快。
4. 序列和可靠性很重要。

*更新問題內容*

如果你有多個服務器需要的pub/sub相互之間/多個端點，什麼是它們之間的通信的推薦模式？一個或多個消息代理將消息重新發布到已發現服務器的名單中？從每個服務器直接可靠的組播？ 如何在分佈式系統中連接多個端點，同時保持低延遲，高速和交付可靠？

Answer 1

假設所有面向客戶端的端點都位於同一個局域網上（它們可以用於擴展的第一個合理步驟），可靠的UDP多播將允許您直接從發佈端點發送發佈的消息到任何有客戶訂閱該頻道的終端。這也比通過持久存儲層代理數據更好地滿足低延遲要求。

多點傳送組

• 中央數據庫（比如說，Redis的）可以跟蹤地圖上的組播組（IP：PORT）< - >信道。
• 當一個端點接收到一個新的客戶端並有一個新的頻道訂閱時，它可以向數據庫詢問該頻道的多播地址並加入多播組。

可靠UDP多播

• 當端點接收用於信道發佈的消息時，它將該消息發送到該信道的多播套接字。
• 消息數據包將包含每個服務器每個多播組的有序標識符。如果端點在未收到來自服務器的前一條消息的情況下收到消息，則它會發送「未確認」消息，以顯示任何錯過它回發佈服務器的消息。
• 發佈服務器跟蹤最近消息的列表，並重新發送NAK'd消息。
• 要處理服務器的邊緣情況，只發送一條消息，並且無法到達服務器，服務器可以在其NAK隊列的整個生存期內向組播組發送數據包計數：「我發送了24條消息」 ，爲其他服務器提供NAK先前消息的機會。

您可能想要實施PGM。

持久性存儲

如果最終存儲數據長期存儲服務可以加入組播組就像終點......但郵件，而不是存儲在數據庫將它們發送到客戶端。