Nginx 的 TCP 負載均衡介紹

Nginx Plus的商業授權版開始具有TCP負載均衡的功能。從Nginx 1.7.7版本開始加入的，現在變成了一個商業收費版本，想要試用，需要在官網申請。也就是說，Nginx除了以前常用的HTTP負載均衡外，Nginx增加基於TCP協議實現的負載均衡方法。

HTTP負載均衡，也就是我們通常所有“七層負載均衡”，工作在第七層“應用層”。而TCP負載均衡，就是我們通常所說的“四層負載均衡”，工作在“網路層”和“傳輸層”。例如，LVS（Linux Virtual Server，Linux虛擬服務）和F5（一種硬體負載均衡裝置），也是屬於“四層負載均衡”。

 

TCP負載均衡的配置方式

Nginx使用了一個新的stream模組來實現TCP負載均衡，這個模組，類似於http和mail模組，允許我們配置一組監聽TCP連線的服務。允許你配置多個服務的TCP連線，通過在upstream的server組中配置proxy_pass指令。

修改nginx.conf檔案，在http模組的統計目錄，新增一個stream模組（和http等同級）：

 

TCP負載均衡的執行原理

當Nginx從監聽埠收到一個新的客戶端連結時，立刻執行路由排程演算法，獲得指定需要連線的服務IP，然後建立一個新的上游連線，連線到指定伺服器。

TCP負載均衡支援Nginx原有的排程演算法，包括Round Robin（預設，輪詢排程），雜湊（選擇一致）等。同時，排程資訊資料也會和健壯性檢測模組一起協作，為每個連線選擇適當的目標上游伺服器。如果使用Hash負載均衡的排程方法，你可以使用$remote_addr（客戶端IP）來達成簡單持久化會話（同一個客戶端IP的連線，總是落到同一個服務server上）。

和其他upstream模組一樣，TCP的stream模組也支援自定義負載均和的轉發權重（配置“weight=2”），還有backup和down的引數，用於踢掉失效的上游伺服器。max_conns引數可以限制一臺伺服器的TCP連線數量，根據伺服器的容量來設定恰當的配置數值，尤其在高併發的場景下，可以達到過載保護的目的。

Nginx監控客戶端連線和上游連線，一旦接收到資料，則Nginx會立刻讀取並且推送到上游連線，不會做TCP連線內的資料檢測。Nginx維護一份記憶體緩衝區，用於客戶端和上游資料的寫入。如果客戶端或者服務端傳輸了量很大的資料，緩衝區會適當增加記憶體的大小。

當Nginx收到任意一方的關閉連線通知，或者TCP連線被閒置超過了proxy_timeout配置的時間，連線將會被關閉。對於TCP長連線，我們更應該選擇適當的proxy_timeout的時間，同時，關注監聽socke的so_keepalive引數，防止過早地斷開連線。

 

服務健壯性監控

TCP負載均衡模組支援內建健壯性檢測，一臺上游伺服器如果拒絕TCP連線超過proxy_connect_timeout配置的時間，將會被認為已經失效。在這種情況下，Nginx立刻嘗試連線upstream組內的另一臺正常的伺服器。連線失敗資訊將會記錄到Nginx的錯誤日誌中。

如果一臺伺服器，反覆失敗（超過了max_fails或者fail_timeout配置的引數），Nginx也會踢掉這臺伺服器。伺服器被踢掉60秒後，Nginx會偶爾嘗試重連它，檢測它是否恢復正常。如果伺服器恢復正常，Nginx將它加回到upstream組內，緩慢加大連線請求的比例。

之所“緩慢加大”，因為通常一個服務都有“熱點資料”，也就是說，80%以上甚至更多的請求，實際都會被阻擋在“熱點資料快取”中，真正執行處理的請求只有很少的一部分。在機器剛剛啟動的時候，“熱點資料快取”實際上還沒有建立，這個時候爆發性地轉發大量請求過來，很可能導致機器無法“承受”而再次掛掉。以mysql為例子，我們的mysql查詢，通常95%以上都是落在了記憶體cache中，真正執行查詢的並不多。

其實，無論是單臺機器或者一個叢集，在高併發請求場景下，重啟或者切換，都存在這個風險，解決的途徑主要是兩種：

（1）請求逐步增加，從少到多，逐步積累熱點資料，最終達到正常服務狀態。
（2）提前準備好“常用”的資料，主動對服務做“預熱”，預熱完成之後，再開放伺服器的訪問。

TCP負載均衡原理上和LVS等是一致的，工作在更為底層，效能會高於原來HTTP負載均衡不少。但是，不會比LVS更為出色，LVS被置於核心模組，而Nginx工作在使用者態，而且，Nginx相對比較重。另外一點，令人感到非常可惜，這個模組竟然是個付費功能。（補註：本文寫於 2015 年 1 月，當初這個模組是收費的）

 

參考資料：

http://nginx.org/