Nginx的TCP負載均衡介紹

Nginx Plus的商業授權版開始具有TCP負載均衡的功能。從Nginx 1.7.7版本開始加入的,現在變成了一個商業收費版本,想要試用,需要在官網申請。也就是說,Nginx除了以前常用的HTTP負載均衡外,Nginx增加基於TCP協議實現的負載均衡方法。HTTP負載均衡,也就是我們通常所有“七層負載均衡”,工作在第七層“應用層”。而TCP負載均衡,就是我們通常所說的“四層負載均衡”,工作在“網絡層”和“傳輸層”。例如,LVS(Linux Virtual Server,Linux虛擬服務)和F5(一種硬件負載均衡設備),也是屬於“四層負載均衡”。
Nginx的TCP負載均衡介紹 - 徐漢彬Hansion - 技術行者
 

TCP負載均衡的配置方式
Nginx使用了一個新的stream模塊來實現TCP負載均衡,這個模塊,類似於http和mail模塊,允許我們配置一組監聽TCP連接的服務。允許你配置多個服務的TCP連接,通過在upstream的server組中配置proxy_pass指令。
修改nginx.conf文件,在http模塊的統計目錄,添加一個stream模塊(和http等同級):
stream {
    server {
        listen 1034;
        proxy_pass app;
    }

    upstream app {
        server 192.168.0.3:1034;
        server 192.168.0.4:1034;
        server 192.168.0.6:1034;
    }
}

TCP負載均衡的執行原理
當Nginx從監聽端口收到一個新的客戶端鏈接時,立刻執行路由調度算法,獲得指定需要連接的服務IP,然後創建一個新的上游連接,連接到指定服務器。
Nginx的TCP負載均衡介紹 - 徐漢彬Hansion - 技術行者

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負載均衡介紹 - 徐漢彬Hansion - 技術行者

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

服務健壯性監控
TCP負載均衡模塊支持內置健壯性檢測,一臺上游服務器如果拒絕TCP連接超過proxy_connect_timeout配置的時間,將會被認爲已經失效。在這種情況下,Nginx立刻嘗試連接upstream組內的另一臺正常的服務器。連接失敗信息將會記錄到Nginx的錯誤日誌中
Nginx的TCP負載均衡介紹 - 徐漢彬Hansion - 技術行者
如果一臺服務器,反覆失敗(超過了max_fails或者fail_timeout配置的參數),Nginx也會踢掉這臺服務器。服務器被踢掉60秒後,Nginx會偶爾嘗試重連它,檢測它是否恢復正常。如果服務器恢復正常,Nginx將它加回到upstream組內,緩慢加大連接請求的比例。

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

其實,無論是單臺機器或者一個集羣,在高併發請求場景下,重啓或者切換,都存在這個風險,解決的途徑主要是兩種:
(1)請求逐步增加,從少到多,逐步積累熱點數據,最終達到正常服務狀態。
(2)提前準備好“常用”的數據,主動對服務做“預熱”,預熱完成之後,再開放服務器的訪問。

TCP負載均衡原理上和LVS等是一致的,工作在更爲底層,性能會高於原來HTTP負載均衡不少。但是,不會比LVS更爲出色,LVS被置於內核模塊,而Nginx工作在用戶態,而且,Nginx相對比較重。另外一點,令人感到非常可惜,這個模塊竟然是個付費功能。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章