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

[[276718]]

nginx-1.9.0 已發布，該版本增加了stream 模塊用于一般的TCP 代理和負載均衡，ngx_stream_core_module 這個模塊在1.90版本后將被啟用。但是并不會默認安裝， 
需要在編譯時通過指定 --with-stream 參數來激活這個模塊。 
  
1）配置Nginx編譯文件參數 
./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; #需要監聽的端口 
 proxy_timeout 20s; 
 proxy_pass kevin; 
 } 
} 
  
創建最高級別的stream（與http同一級別），定義一個upstream組 名稱為kevin，由多個服務組成達到負載均衡 定義一個服務用來監聽TCP連接（如：8081端口）， 
并且把他們代理到一個upstream組的kevin中，配置負載均衡的方法和參數為每個server；配置些如：連接數、權重等等。 
  
首先創建一個server組，用來作為TCP負載均衡組。定義一個upstream塊在stream上下文中，在這個塊里面添加由server命令定義的server，指定他的IP地址和 
主機名（能夠被解析成多地址的主機名)和端口號。下面的例子是建立一個被稱之為kevin組，兩個監聽1395端口的server ，一個監聽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定義協議，因為這個stream命令建立TCP作為整個 server的協議了。 
  
配置反向代理使Nginx能夠把TCP請求從一個客戶端轉發到負載均衡組中(如：kevin組)。在每個server配置塊中 通過每個虛擬server的server的配置信息和在 
每個server中定義的監聽端口（客戶端需求的代理端口號，如我推流的的是kevin協議，則端口號為：8081）的配置信息和proxy_passs 命令把TCP通信發送到 
upstream的哪個server中去。下面我們將TCP通信發送到kevin 組中去。 
  
 server { 
 listen 8081; #需要監聽的端口 
 proxy_timeout 20s; 
 proxy_pass kevin; 
 } 
  
當然我們也可以采用單一的代理方式： 
  
server { 
 listen 8081; #需要監聽的端口 
 proxy_timeout 20s; 
 proxy_pass 192.168.10.30:8081; #需要代理的端口，在這里我代理一一個kevin模塊的接口8081 
} 
------------------------------------------------------------------ 
  
4）改變負載均衡的方法： 
默認nginx是通過輪詢算法來進行負載均衡的通信的。引導這個請求循環的到配置在upstream組中server端口上去。 因為他是默認的方法，這里沒有輪詢命令， 
只是簡單的創建一個upstream配置組在這兒stream山下文中，而且在其中添加server。 
  
a）least-connected ：對于每個請求，nginx plus選擇當前連接數最少的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命令中指定的參數計算出來的： 
connect：連接到一個server所花的時間 
first_byte：接收到第一個字節的時間 
last_byte：全部接收完了的時間 最少活躍的連接數: 
  
　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 關鍵字，就是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負載均衡的執行原理

當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參數，防止過早地斷開連接。

Nginx的TCP負載均衡服務健壯性監控

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相對比較重。另外一點，令人感到非常可惜，這個模塊竟然是個付費功能。