水平縮放服務器之間共享輸入的應用程序

Question

我正在構建一個應用程序，該應用程序通過必須共享回可能連接到其他前端服務器的其他客戶端的websocket接受輸入。

爲了簡單起見，想象一下多用戶多房間聊天應用程序。將輸入路由到正確的連接並不是一個問題，它是服務器之間的消息傳遞，並能夠擴展並保持消息的延遲。

現在我有一個每個前端連接到的代理程序，然後他們訂閱一個隊列來查看它的連接可能需要知道的任何事情。這樣做是爲了切斷接收來自前端永遠不會使用的代理的消息。但是，我仍然可以獲得大約75％到85％的消息從經紀商發回到每個前端。

在旅行中我正在做消息驗證，解析和任何其他業務邏輯工作。在旅途中，我正在遍歷本地數組以獲得訂閱，並將消息發送到每個訂閱的連接。

舉例：如果我在11個前端服務器上收到10條消息（總計110條消息 - 10條消息在本地處理並且不由代理髮回）* 0.75樂觀預訂級別= 75條消息被髮回到每個服務器來處理。所以我們有10個本地+75個broker = 85個消息被每個服務器處理一段時間。

現在，我不會有100個每秒鐘100個前端服務器，也許是兩個，但是由代理進程發送回每個前端服務器的消息似乎會爆炸我通過其他前端服務器收到的更多消息。

代理進程是一個與RabbitMQ和PostgreSQL進行對話的小型node.js應用程序。前端服務器也是node.js應用程序。

我可以做什麼或者我應該採取不同的措施來保持大批量生產期間的低延遲？

更新回覆用戶評論：雖然我期望隊列之間有很多重疊，連接將導致其前端服務器訂閱，但我不認爲它對於每個服務器都是100％。最糟糕的情況是，每個前端服務器都必須訂閱代理上的每個隊列，從而從代理獲得100％的消息。樂觀地說，只有大約75％的消息確實需要被髮送回任何特定的前端服務器。

itaifrenkel的第二次更新：兩個用戶發送的消息可能以不同的順序返回。只有在延遲非常低時纔可以接受，並且只有在發送的消息非常接近時纔會發生。如果它發生在相隔幾秒的消息中，那麼我會說我們有一個延遲和規模問題。

有一種情況我們需要顯示一個歷史記錄，但是由於我覺得它超出了問題的範圍，所以我沒有這樣做。

Answer 1

消息隊列解決方案聽起來像是正確的選項。正如你在標題中所建議的那樣，爲了擴展這一點，你需要水平。

我還沒有和RabbitMQ合作過，所以我不能用細節吹你，但水平縮放意味着一個集羣，所以http://www.rabbitmq.com/clustering.html可能足以讓你去。

Answer 2

我們假設每個用戶在任何時間只連接到一個聊天室。這意味着一個websocket連接=一個聊天室。所以你會寫一個額外的節點。js反向代理將每個用戶連接轉發到最有可能正在監聽聊天室事件的「前端」node.js進程（使用基於聊天室標識的一致哈希的聊天室關聯）。該路由算法需要盡最大努力提高網絡利用率，但並不需要完美。

現在讓我們允許每個用戶在多個聊天室中。然後，您需要改進反向代理以連接到多個「前端」服務器，並將結果複用回用戶。

此設計將提供橫向擴展性的網絡延遲費用。

注意：當然，新的反向代理現在是前端服務器，但是當我提到「前端」時，我指的是服務器，正如您在問題中描述的那樣。