默認(rèn)nginx不支持tcp的負(fù)載均衡，需要打補(bǔ)丁，(連接方式：從客戶端收到一個(gè)連接，將從本地新建一個(gè)連接發(fā)起到后端服務(wù)器)，具體配置如下：

一、安裝Nginx
1.下載nginx

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

2.下載tcp模塊補(bǔ)丁

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

源碼主頁(yè)： 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;
}
}

三、啟動(dòng)nginx

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

查看1433端口：

#lsof :1433

四、測(cè)試

# telnet 10.0.1.201 1433

五、使用sql server client工具測(cè)試

六、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）來達(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ù)器的容量來設(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)嚅_連接。

PS：服務(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)求過來，很可能導(dǎo)致機(jī)器無法“承受”而再次掛掉。以mysql為例子，我們的mysql查詢，通常95%以上都是落在了內(nèi)存cache中，真正執(zhí)行查詢的并不多。

其實(shí)，無論是單臺(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ì)高于原來HTTP負(fù)載均衡不少。但是，不會(huì)比LVS更為出色，LVS被置于內(nèi)核模塊，而Nginx工作在用戶態(tài)，而且，Nginx相對(duì)比較重。另外一點(diǎn)，令人感到非常可惜，這個(gè)模塊竟然是個(gè)付費(fèi)功能。

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)求過來，很可能導(dǎo)致機(jī)器無法“承受”而再次掛掉。以mysql為例子，我們的mysql查詢，通常95%以上都是落在了內(nèi)存cache中，真正執(zhí)行查詢的并不多。

其實(shí)，無論是單臺(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ì)高于原來HTTP負(fù)載均衡不少。但是，不會(huì)比LVS更為出色，LVS被置于內(nèi)核模塊，而Nginx工作在用戶態(tài)，而且，Nginx相對(duì)比較重。另外一點(diǎn)，令人感到非?？上?，這個(gè)模塊竟然是個(gè)付費(fèi)功能。

最新評(píng)論