如何擴充支援長輪詢的 Web 伺服器

如何擴充支援長輪詢的 Web 伺服器

我計劃添加更多的 Web 應用程式伺服器來支援不斷增加的客戶端,部署 HAproxy 和 Keepalived 來實現負載平衡和高可用性。

我的伺服器使用有以下特點:

  1. 作業不是 CPU 密集的。訊息是少於 100 個字元的 JSON 文字。
  2. 用戶將透過客戶端設備Y向伺服器發送訊息。
  3. 客戶端設備X繼續等待來自伺服器的訊息。如果伺服器上有訊息,則用戶端裝置 X 必須能夠在 2 秒內取得該訊息。否則,此訊息已過時。

為此原因,

  1. X 正在使用的用戶端設備長輪詢 HTTP 連接以便做出反應。每次連線將持續 5 秒並重新連線。
  2. 客戶端設備X和客戶端設備Y連接到同一伺服器,因此X和Y可以輕鬆發送訊息

問題

如果有超過 60,000 個客戶端設備 X 連接到伺服器,我的負載平衡器或路由器將耗盡 TCP 連接埠。擴大規模(例如 20,000 個用戶)的最佳方法是什麼?

我的伺服器運行在Ubuntu伺服器上,使用tomcat和Java Servlet。

答案1

我不認為你的 60k 客戶是真正的問題。您很可能會遇到檔案描述符不足的問題,但這作為作業系統配置的一部分應該很容易修復。

這就是為什麼連線不會成為您的問題。每個連接都由其來源 IP 位址、來源連接埠、目標 IP 位址和目標連接埠來表徵。在網路堆疊內部,這個四元組用於將資料包與檔案描述符進行匹配(每個檔案描述符代表一個連接)。您的伺服器具有固定的目標 IP 位址和目標連接埠(您的伺服器是其用戶端的目標),但來源 IP 位址和來源連接埠是可變的。連接埠是一個 16 位元數字,因此一個客戶端的最大連線數為 64K。 IPv4 位址是一個 32 位元數字,可為您提供 4,294,967,296 個可能的來源位址。做一些基本的數學計算,您的伺服器可能有 64K * 4,294,967,296 個連接映射到單一來源 IP 和連接埠。

這就是為什麼您更有可能遇到開啟檔案描述符最大數量問題而不是客戶端數量問題。

答案2

最簡單的方法可能是在 DNS 層級實現負載平衡。

意思是:有一個循環 DNS 項目,可以平衡 2 個、3 個或更多實體負載平衡器。

相關內容