在Nginx服務器中怎么配置針對TCP的負載均衡

今天小編給大家分享一下在Nginx服務器中怎么配置針對TCP的負載均衡的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

一、安裝nginx
1.下載nginx

# wget http://nginx.org/download/nginx-1.2.4.tar.gz

2.下載tcp模塊補丁

# wget https://github.com/yaoweibin/nginx_tcp_proxy_module/tarball/master

源碼主頁： https://github.com/yaoweibin/nginx_tcp_proxy_module

3.安裝nginx

# tar xvf nginx-1.2.4.tar.gz
# tar xvf yaoweibin-nginx_tcp_proxy_module-v0.4-45-ga40c99a.tar.gz
# cd nginx-1.2.4
# patch -p1 < ../yaoweibin-nginx_tcp_proxy_module-a40c99a/tcp.patch
#./configure --prefix=/usr/local/nginx --with-pcre=../pcre-8.30 --add-module=../yaoweibin-nginx_tcp_proxy_module-ae321fd/
# make
# make install

二、修改配置文件
修改nginx.conf配置文件

# cd /usr/local/nginx/conf
# vim nginx.conf

worker_processes 1;
events {
worker_connections 1024;
}

tcp {
upstream mssql {
server 10.0.1.201:1433;
server 10.0.1.202:1433;
check interval=3000 rise=2 fall=5 timeout=1000;
}
server {
listen 1433;
server_name 10.0.1.212;
proxy_pass mssql;
}
}

三、啟動nginx

# cd /usr/local/nginx/sbin/
# ./nginx

查看1433端口：

#lsof :1433

四、測試

# telnet 10.0.1.201 1433

五、使用sql server client工具測試

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

ps：服務健壯性監控

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

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

以上就是“在Nginx服務器中怎么配置針對TCP的負載均衡”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。