HTTP負(fù)載均衡，也就是我們通常所有"七層負(fù)載均衡"，工作在第七層"應(yīng)用層"。而TCP負(fù)載均衡，就是我們通常所說的"四層負(fù)載均衡"，工作在"網(wǎng)絡(luò)層"和"傳輸層"。例如，LVS(Linux Virtual Server，Linux虛擬服務(wù))和F5(一種硬件負(fù)載均衡設(shè)備)，也是屬于"四層負(fù)載均衡"
Nginx的TCP負(fù)載均衡的執(zhí)行原理
當(dāng)Nginx從監(jiān)聽端口收到一個(gè)新的客戶端鏈接時(shí)，立刻執(zhí)行路由調(diào)度算法，獲得指定需要連接的服務(wù)IP，然后創(chuàng)建一個(gè)新的上游連接，連接到指定服務(wù)器。
TCP負(fù)載均衡支持Nginx原有的調(diào)度算法，包括Round Robin(默認(rèn)，輪詢調(diào)度)，哈希(選擇一致)等。同時(shí)，調(diào)度信息數(shù)據(jù)也會(huì)和健壯性檢測(cè)模塊一起協(xié)作，為每個(gè)連接選擇適當(dāng)?shù)哪繕?biāo)上游服務(wù)器。如果使用Hash負(fù)載均衡的調(diào)度方法，你可以使用$remote_addr(客戶端IP)來(lái)達(dá)成簡(jiǎn)單持久化會(huì)話(同一個(gè)客戶端IP的連接，總是落到同一個(gè)服務(wù)server上)。
和其他upstream模塊一樣，TCP的stream模塊也支持自定義負(fù)載均和的轉(zhuǎn)發(fā)權(quán)重(配置“weight=2”)，還有backup和down的參數(shù)，用于踢掉失效的上游服務(wù)器。max_conns參數(shù)可以限制一臺(tái)服務(wù)器的TCP連接數(shù)量，根據(jù)服務(wù)器的容量來(lái)設(shè)置恰當(dāng)?shù)呐渲脭?shù)值，尤其在高并發(fā)的場(chǎng)景下，可以達(dá)到過載保護(hù)的目的。
Nginx監(jiān)控客戶端連接和上游連接，一旦接收到數(shù)據(jù)，則Nginx會(huì)立刻讀取并且推送到上游連接，不會(huì)做TCP連接內(nèi)的數(shù)據(jù)檢測(cè)。Nginx維護(hù)一份內(nèi)存緩沖區(qū)，用于客戶端和上游數(shù)據(jù)的寫入。如果客戶端或者服務(wù)端傳輸了量很大的數(shù)據(jù)，緩沖區(qū)會(huì)適當(dāng)增加內(nèi)存的大小。
當(dāng)Nginx收到任意一方的關(guān)閉連接通知，或者TCP連接被閑置超過了proxy_timeout配置的時(shí)間，連接將會(huì)被關(guān)閉。對(duì)于TCP長(zhǎng)連接，我們更應(yīng)該選擇適當(dāng)?shù)膒roxy_timeout的時(shí)間，同時(shí)，關(guān)注監(jiān)聽socke的so_keepalive參數(shù)，防止過早地?cái)嚅_連接。
Nginx的TCP負(fù)載均衡服務(wù)健壯性監(jiān)控
TCP負(fù)載均衡模塊支持內(nèi)置健壯性檢測(cè)，一臺(tái)上游服務(wù)器如果拒絕TCP連接超過proxy_connect_timeout配置的時(shí)間，將會(huì)被認(rèn)為已經(jīng)失效。在這種情況下，Nginx立刻嘗試連接upstream組內(nèi)的另一臺(tái)正常的服務(wù)器。連接失敗信息將會(huì)記錄到Nginx的錯(cuò)誤日志中。
如果一臺(tái)服務(wù)器，反復(fù)失敗(超過了max_fails或者fail_timeout配置的參數(shù))，Nginx也會(huì)踢掉這臺(tái)服務(wù)器。服務(wù)器被踢掉60秒后，Nginx會(huì)偶爾嘗試重連它，檢測(cè)它是否恢復(fù)正常。如果服務(wù)器恢復(fù)正常，Nginx將它加回到upstream組內(nèi)，緩慢加大連接請(qǐng)求的比例。
之所"緩慢加大"，因?yàn)橥ǔＲ粋€(gè)服務(wù)都有"熱點(diǎn)數(shù)據(jù)"，也就是說，80%以上甚至更多的請(qǐng)求，實(shí)際都會(huì)被阻擋在"熱點(diǎn)數(shù)據(jù)緩存"中，真正執(zhí)行處理的請(qǐng)求只有很少的一部分。在機(jī)器剛剛啟動(dòng)的時(shí)候，"熱點(diǎn)數(shù)據(jù)緩存"實(shí)際上還沒有建立，這個(gè)時(shí)候爆發(fā)性地轉(zhuǎn)發(fā)大量請(qǐng)求過來(lái)，很可能導(dǎo)致機(jī)器無(wú)法"承受"而再次掛掉。以mysql為例子，我們的mysql查詢，通常95%以上都是落在了內(nèi)存cache中，真正執(zhí)行查詢的并不多。
其實(shí)，無(wú)論是單臺(tái)機(jī)器或者一個(gè)集群，在高并發(fā)請(qǐng)求場(chǎng)景下，重啟或者切換，都存在這個(gè)風(fēng)險(xiǎn)，解決的途徑主要是兩種：
1)請(qǐng)求逐步增加，從少到多，逐步積累熱點(diǎn)數(shù)據(jù)，最終達(dá)到正常服務(wù)狀態(tài)。
2)提前準(zhǔn)備好"常用"的數(shù)據(jù)，主動(dòng)對(duì)服務(wù)做"預(yù)熱"，預(yù)熱完成之后，再開放服務(wù)器的訪問。
TCP負(fù)載均衡原理上和LVS等是一致的，工作在更為底層，性能會(huì)高于原來(lái)HTTP負(fù)載均衡不少。但是，不會(huì)比LVS更為出色，LVS被置于內(nèi)核模塊，而Nginx工作在用戶態(tài)，而且，Nginx相對(duì)比較重。另外一點(diǎn)，令人感到非?？上В@個(gè)模塊竟然是個(gè)付費(fèi)功能。
【責(zé)任編輯：武曉燕 TEL：（010）68476606】