HTTP負載均衡，也就是我們通常所有"七層負載均衡"，工作在第七層"應(yīng)用層"。而TCP負載均衡，就是我們通常所說的"四層負載均衡"，工作在"網(wǎng)絡(luò)層"和"傳輸層"。例如，LVS(Linux Virtual Server，Linux虛擬服務(wù))和F5(一種硬件負載均衡設(shè)備)，也是屬于"四層負載均衡"

[[276718]]

nginx-1.9.0 已發(fā)布，該版本增加了stream 模塊用于一般的TCP 代理和負載均衡，ngx_stream_core_module 這個模塊在1.90版本后將被啟用。但是并不會默認安裝， 
需要在編譯時通過指定 --with-stream 參數(shù)來激活這個模塊。 
  
1）配置Nginx編譯文件參數(shù) 
./configure --with-http_stub_status_module --with-stream 
------------------------------------------------------------------ 
  
2）編譯、安裝，make && make install 
------------------------------------------------------------------ 
  
3）配置nginx.conf文件 
  
stream { 
 upstream kevin { 
 server 192.168.10.10:8080; #這里配置成要訪問的地址 
 server 192.168.10.20:8081; 
 server 192.168.10.30:8081; #需要代理的端口，在這里我代理一一個kevin模塊的接口8081 
 } 
 server { 
 listen 8081; #需要監(jiān)聽的端口 
 proxy_timeout 20s; 
 proxy_pass kevin; 
 } 
} 
  
創(chuàng)建最高級別的stream（與http同一級別），定義一個upstream組 名稱為kevin，由多個服務(wù)組成達到負載均衡 定義一個服務(wù)用來監(jiān)聽TCP連接（如：8081端口）， 
并且把他們代理到一個upstream組的kevin中，配置負載均衡的方法和參數(shù)為每個server；配置些如：連接數(shù)、權(quán)重等等。 
  
首先創(chuàng)建一個server組，用來作為TCP負載均衡組。定義一個upstream塊在stream上下文中，在這個塊里面添加由server命令定義的server，指定他的IP地址和 
主機名（能夠被解析成多地址的主機名)和端口號。下面的例子是建立一個被稱之為kevin組，兩個監(jiān)聽1395端口的server ，一個監(jiān)聽8080端口的server。 
  
upstream kevin { 
 server 192.168.10.10:8080; #這里配置成要訪問的地址 
 server 192.168.10.20:8081; 
 server 192.168.10.30:8081; #需要代理的端口，在這里我代理一一個kevin模塊的接口8081 
 } 
  
  
需要特別注意的是： 
你不能為每個server定義協(xié)議，因為這個stream命令建立TCP作為整個 server的協(xié)議了。 
  
配置反向代理使Nginx能夠把TCP請求從一個客戶端轉(zhuǎn)發(fā)到負載均衡組中(如：kevin組)。在每個server配置塊中 通過每個虛擬server的server的配置信息和在 
每個server中定義的監(jiān)聽端口（客戶端需求的代理端口號，如我推流的的是kevin協(xié)議，則端口號為：8081）的配置信息和proxy_passs 命令把TCP通信發(fā)送到 
upstream的哪個server中去。下面我們將TCP通信發(fā)送到kevin 組中去。 
  
 server { 
 listen 8081; #需要監(jiān)聽的端口 
 proxy_timeout 20s; 
 proxy_pass kevin; 
 } 
  
當(dāng)然我們也可以采用單一的代理方式： 
  
server { 
 listen 8081; #需要監(jiān)聽的端口 
 proxy_timeout 20s; 
 proxy_pass 192.168.10.30:8081; #需要代理的端口，在這里我代理一一個kevin模塊的接口8081 
} 
------------------------------------------------------------------ 
  
4）改變負載均衡的方法： 
默認nginx是通過輪詢算法來進行負載均衡的通信的。引導(dǎo)這個請求循環(huán)的到配置在upstream組中server端口上去。 因為他是默認的方法，這里沒有輪詢命令， 
只是簡單的創(chuàng)建一個upstream配置組在這兒stream山下文中，而且在其中添加server。 
  
a）least-connected ：對于每個請求，nginx plus選擇當(dāng)前連接數(shù)最少的server來處理: 
  
　upstream kevin { 
　　　　least_conn; 
 server 192.168.10.10:8080; #這里配置成要訪問的地址 
 server 192.168.10.20:8081; 
 server 192.168.10.30:8081; #需要代理的端口，在這里我代理一一個kevin模塊的接口8081 
 } 
  
b）least time ：對于每個鏈接,nginx pluns 通過幾點來選擇server的： 最底平均延時：通過包含在least_time命令中指定的參數(shù)計算出來的： 
connect：連接到一個server所花的時間 
first_byte：接收到第一個字節(jié)的時間 
last_byte：全部接收完了的時間 最少活躍的連接數(shù): 
  
　upstream kevin { 
　　　　least_time first_byte; 
 server 192.168.10.10:8080; #這里配置成要訪問的地址 
 server 192.168.10.20:8081; 
 server 192.168.10.30:8081; #需要代理的端口，在這里我代理一一個kevin模塊的接口8081 
 } 
  
c）普通的hash算法：nginx plus選擇這個server是通過user_defined 關(guān)鍵字，就是IP地址：$remote_addr; 
  
　　upstream kevin { 
　　　　hash $remote_addr consistent; 
 server 192.168.10.10:8080 weight=5; #這里配置成要訪問的地址 
 server 192.168.10.20:8081 max_fails=2 fail_timeout=30s; 
 server 192.168.10.30:8081 max_conns=3; #需要代理的端口，在這里我代理一一個kevin模塊的接口8081 
 } 

Nginx的TCP負載均衡的執(zhí)行原理

當(dāng)Nginx從監(jiān)聽端口收到一個新的客戶端鏈接時，立刻執(zhí)行路由調(diào)度算法，獲得指定需要連接的服務(wù)IP，然后創(chuàng)建一個新的上游連接，連接到指定服務(wù)器。

TCP負載均衡支持Nginx原有的調(diào)度算法，包括Round Robin(默認，輪詢調(diào)度)，哈希(選擇一致)等。同時，調(diào)度信息數(shù)據(jù)也會和健壯性檢測模塊一起協(xié)作，為每個連接選擇適當(dāng)?shù)哪繕?biāo)上游服務(wù)器。如果使用Hash負載均衡的調(diào)度方法，你可以使用$remote_addr(客戶端IP)來達成簡單持久化會話(同一個客戶端IP的連接，總是落到同一個服務(wù)server上)。

和其他upstream模塊一樣，TCP的stream模塊也支持自定義負載均和的轉(zhuǎn)發(fā)權(quán)重(配置“weight=2”)，還有backup和down的參數(shù)，用于踢掉失效的上游服務(wù)器。max_conns參數(shù)可以限制一臺服務(wù)器的TCP連接數(shù)量，根據(jù)服務(wù)器的容量來設(shè)置恰當(dāng)?shù)呐渲脭?shù)值，尤其在高并發(fā)的場景下，可以達到過載保護的目的。

Nginx監(jiān)控客戶端連接和上游連接，一旦接收到數(shù)據(jù)，則Nginx會立刻讀取并且推送到上游連接，不會做TCP連接內(nèi)的數(shù)據(jù)檢測。Nginx維護一份內(nèi)存緩沖區(qū)，用于客戶端和上游數(shù)據(jù)的寫入。如果客戶端或者服務(wù)端傳輸了量很大的數(shù)據(jù)，緩沖區(qū)會適當(dāng)增加內(nèi)存的大小。

當(dāng)Nginx收到任意一方的關(guān)閉連接通知，或者TCP連接被閑置超過了proxy_timeout配置的時間，連接將會被關(guān)閉。對于TCP長連接，我們更應(yīng)該選擇適當(dāng)?shù)膒roxy_timeout的時間，同時，關(guān)注監(jiān)聽socke的so_keepalive參數(shù)，防止過早地斷開連接。

Nginx的TCP負載均衡服務(wù)健壯性監(jiān)控

TCP負載均衡模塊支持內(nèi)置健壯性檢測，一臺上游服務(wù)器如果拒絕TCP連接超過proxy_connect_timeout配置的時間，將會被認為已經(jīng)失效。在這種情況下，Nginx立刻嘗試連接upstream組內(nèi)的另一臺正常的服務(wù)器。連接失敗信息將會記錄到Nginx的錯誤日志中。

如果一臺服務(wù)器，反復(fù)失敗(超過了max_fails或者fail_timeout配置的參數(shù))，Nginx也會踢掉這臺服務(wù)器。服務(wù)器被踢掉60秒后，Nginx會偶爾嘗試重連它，檢測它是否恢復(fù)正常。如果服務(wù)器恢復(fù)正常，Nginx將它加回到upstream組內(nèi)，緩慢加大連接請求的比例。

之所"緩慢加大"，因為通常一個服務(wù)都有"熱點數(shù)據(jù)"，也就是說，80%以上甚至更多的請求，實際都會被阻擋在"熱點數(shù)據(jù)緩存"中，真正執(zhí)行處理的請求只有很少的一部分。在機器剛剛啟動的時候，"熱點數(shù)據(jù)緩存"實際上還沒有建立，這個時候爆發(fā)性地轉(zhuǎn)發(fā)大量請求過來，很可能導(dǎo)致機器無法"承受"而再次掛掉。以mysql為例子，我們的mysql查詢，通常95%以上都是落在了內(nèi)存cache中，真正執(zhí)行查詢的并不多。

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

1)請求逐步增加，從少到多，逐步積累熱點數(shù)據(jù)，最終達到正常服務(wù)狀態(tài)。

2)提前準(zhǔn)備好"常用"的數(shù)據(jù)，主動對服務(wù)做"預(yù)熱"，預(yù)熱完成之后，再開放服務(wù)器的訪問。

TCP負載均衡原理上和LVS等是一致的，工作在更為底層，性能會高于原來HTTP負載均衡不少。但是，不會比LVS更為出色，LVS被置于內(nèi)核模塊，而Nginx工作在用戶態(tài)，而且，Nginx相對比較重。另外一點，令人感到非常可惜，這個模塊竟然是個付費功能。