HTTP負載均衡，也就是我們通常所有"七層負載均衡"，工作在第七層"應用層"。而TCP負載均衡，就是我們通常所說的"四層負載均衡"，工作在"網絡層"和"傳輸層"。例如，LVS（linux Virtual Server，Linux虛擬服務）和F5（一種硬件負載均衡設備），也是屬于"四層負載均衡"
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相對比較重。另外一點，令人感到非常可惜，這個模塊竟然是個付費功能。
