nginx 判斷節(jié)點失效狀態(tài)：

　Nginx 默認(rèn)判斷失敗節(jié)點狀態(tài)以connect refuse和time out狀態(tài)為準(zhǔn)，不以HTTP錯誤狀態(tài)進(jìn)行判斷失敗，因為HTTP只要能返回狀態(tài)說明該節(jié)點還可以正常連接，所以nginx判斷其還是存活狀態(tài)；

　除非添加了proxy_next_upstream指令設(shè)置對404、502、503、504、500和time out等錯誤進(jìn)行轉(zhuǎn)到備機處理，

　在next_upstream過程中，會對fails進(jìn)行累加，如果備用機處理還是錯誤則直接返回錯誤信息（但404不進(jìn)行記錄到錯誤數(shù)，如果不配置錯誤狀態(tài)也不對其進(jìn)行錯誤狀態(tài)記錄）

　綜述，nginx記錄錯誤數(shù)量只記錄timeout 、connect refuse、502、500、503、504這6種狀態(tài)，timeout和connect refuse是永遠(yuǎn)被記錄錯誤狀態(tài)，

　　　　而502、500、503、504只有在配置proxy_next_upstream后nginx才會記錄這4種HTTP錯誤到fails中，當(dāng)fails大于等于max_fails時，則該節(jié)點失效

nginx 處理節(jié)點失效和恢復(fù)的觸發(fā)條件：

　nginx可以通過設(shè)置max_fails（最大嘗試失敗次數(shù)）和fail_timeout（失效時間，在到達(dá)最大嘗試失敗次數(shù)后，在fail_timeout的時間范圍內(nèi)節(jié)點被置為失效，除非所有節(jié)點都失效，否則該時間內(nèi)，節(jié)點不進(jìn)行恢復(fù)）對節(jié)點失敗的嘗試次數(shù)和失效時間進(jìn)行設(shè)置，

　當(dāng)超過最大嘗試次數(shù)或失效時間未超過配置失效時間，則nginx會對節(jié)點狀會置為失效狀態(tài)，nginx不對該后端進(jìn)行連接，直到超過失效時間或者所有節(jié)點都失效后，該節(jié)點重新置為有效，重新探測；

所有節(jié)點失效后nginx將重新恢復(fù)所有節(jié)點進(jìn)行探測：

　如果探測所有節(jié)點均失效，備機也為失效時，那么nginx會對所有節(jié)點恢復(fù)為有效，重新嘗試探測有效節(jié)點，如果探測到有效節(jié)點則返回正確節(jié)點內(nèi)容，如果還是全部錯誤，那么繼續(xù)探測下去，

　當(dāng)沒有正確信息時，節(jié)點失效時默認(rèn)返回狀態(tài)為502，但是下次訪問節(jié)點時會繼續(xù)探測正確節(jié)點，直到找到正確的為止。

一、ngx_http_proxy_module模塊和ngx_http_upstream_module模塊（自帶）

　Nginx 在 upstream 模塊中的默認(rèn)檢測機制：通過用戶的真實請求去檢查被代理服務(wù)器的可用性，這是一種被動的檢測機制，通過 ngx_http_upstream_module 模塊中 server 指令的指令值參數(shù) max_fails 及 fail_timeout 實現(xiàn)對被代理服務(wù)器的檢測和熔斷。

upstream test1 {
#10s內(nèi)出現(xiàn)3次錯誤，該服務(wù)器將被熔斷10s server 192.168.134.154:80 max_fails=3 fails_timeout=10s; server 192.168.134.153:80 max_fails=3 fails_timeout=10s; server 192.168.134.152:80 max_fails=3 fails_timeout=10s; } server { proxy_connect_timeout 5s;　　　　　　#與被代理服務(wù)器建立連接的超時時間 proxy_read_timeout 10s;　　　　　　　#獲取被代理服務(wù)器的響應(yīng)最大超時時間,當(dāng)與被代理服務(wù)器通信出現(xiàn)指令值指定的情況時，認(rèn)為被代理出錯，并將請求轉(zhuǎn)發(fā)給上游服務(wù)器組中的下一個可用服務(wù)器 proxy_next_upstream http_502 http_504 http_404 error timeout invalid_header; proxy_next_upstream_teies 3;　　　　#轉(zhuǎn)發(fā)請求最大次數(shù) proxy_next_upstream_timeout 10s;　 #總嘗試超時時間

　　max_fails：   10s 內(nèi) Nginx 分配給當(dāng)前服務(wù)器的請求失敗次數(shù)累加值，每 10s 會重置為 0

　　fail_timeout：既是失敗計數(shù)的最大時間，又是服務(wù)器被置為失敗狀態(tài)的熔斷時間，超過這個時間將再次被分配

　　指令 proxy_connect_timeout 或 proxy_read_timeout 為超時狀態(tài)時，都會觸發(fā) proxy_next_upstream 的 timeout 條件

　　proxy_next_upstream：Nginx 提高請求成功率的機制，當(dāng)被代理服務(wù)器返回錯誤并符合 proxy_next_upstream 指令值設(shè)置的條件時，將嘗試轉(zhuǎn)發(fā)給下一個可用的被代理服務(wù)器

　Nginx 被動檢測機制的優(yōu)點是不需要增加額外進(jìn)程進(jìn)行健康檢測，但用該方法檢測是不準(zhǔn)確的。如當(dāng)響應(yīng)超時時，有可能是被代理服務(wù)器故障，也可能是業(yè)務(wù)響應(yīng)慢引起的。

　如果是被代理服務(wù)器故障，那么 Nginx 仍會在一定時間內(nèi)將客戶端的請求轉(zhuǎn)發(fā)給該服務(wù)器，用以判斷其是否恢復(fù)。

二、nginx_upstream_check_module模塊（淘寶技術(shù)團(tuán)隊開發(fā)）

檢測后方realserver的健康狀態(tài)，如果后端服務(wù)器不可用，則會將其踢出upstream，所有的請求不轉(zhuǎn)發(fā)到這臺服務(wù)器；當(dāng)恢復(fù)正常時，將其加入upstream

upstream test1 { server 192.168.134.154:80; server 192.168.134.153:80; server 192.168.134.152:80;
#每隔5秒檢測一次，請求2次正常則標(biāo)記 realserver狀態(tài)為up，如果檢測5次都失敗，則標(biāo)記 realserver的狀態(tài)為down，超時時間為1秒，使用http協(xié)議。 check interval=5000 rise=2 fall=5 timeout=1000 type=http; check_http_send"HEAD / HTTP/1.0rnrn"; check_http_expect_alive http_2xx http_3xx; }

Syntax: check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port] Default: 如果沒有配置參數(shù)，默認(rèn)值是：interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp Context: upstream

參數(shù)說明：

參數(shù) 描述 interval 向后端發(fā)送的健康檢查包的間隔 fall(fall_count) 如果連續(xù)失敗次數(shù)達(dá)到fall_count，服務(wù)器就被認(rèn)為是down rise(rise_count) 如果連續(xù)成功次數(shù)達(dá)到rise_count，服務(wù)器就被認(rèn)為是up timeout 后端健康請求的超時時間，單位毫秒 default_down 設(shè)定初始時服務(wù)器的狀態(tài)，如果是true，就說明默認(rèn)是down的，如果是false，就是up的。默認(rèn)值是true，也就是一開始服務(wù)器認(rèn)為是不可用，要等健康檢查包達(dá)到一定成功次數(shù)以后才會被認(rèn)為是健康的 type 健康檢查包的類型，現(xiàn)在支持以下多種類型：   tcp：簡單的tcp連接，如果連接成功，就說明后端正常   ssl_hello：發(fā)送一個初始的SSL hello包并接受服務(wù)器的SSL hello包   http：發(fā)送HTTP請求，通過后端的回復(fù)包的狀態(tài)來判斷后端是否存活   mysql: 向mysql服務(wù)器連接，通過接收服務(wù)器的greeting包來判斷后端是否存活   ajp：向后端發(fā)送AJP協(xié)議的Cping包，通過接收Cpong包來判斷后端是否存活   port: 指定后端服務(wù)器的檢查端口?？梢灾付ú煌谡鎸嵎?wù)的后端服務(wù)器的端口，默認(rèn)是0，表示跟后端server提供真實服務(wù)的端口一樣

Syntax: check_http_send http_packet Default: "GET / HTTP/1.0rnrn" Context: upstream #該指令可以配置http健康檢查包發(fā)送的請求內(nèi)容。為了減少傳輸數(shù)據(jù)量，推薦采用"HEAD"方法。
#當(dāng)采用長連接進(jìn)行健康檢查時，需在該指令中添加keep-alive請求頭，如："HEAD / HTTP/1.1rnConnection: keep-alivernrn"。
#同時，在采用"GET"方法的情況下，請求uri的size不宜過大，確保可以在1個interval內(nèi)傳輸完成，否則會被健康檢查模塊視為后端服務(wù)器或網(wǎng)絡(luò)異常。

Syntax: check_http_expect_alive [ http_2xx | http_3xx | http_4xx | http_5xx ] Default: http_2xx | http_3xx Context: upstream #該指令指定HTTP回復(fù)的成功狀態(tài)，默認(rèn)認(rèn)為2XX和3XX的狀態(tài)是健康的。

Syntax: check_shm_size size Default: 1M Context: http #所有的后端服務(wù)器健康檢查狀態(tài)都存于共享內(nèi)存中，該指令可以設(shè)置共享內(nèi)存的大小。默認(rèn)是1M，如果有1千臺以上的服務(wù)器并在配置的時候出現(xiàn)了錯誤，就可能需要擴(kuò)大該內(nèi)存的大小。

Syntax: check_keepalive_requests request_num Default: 1 Context: upstream #該指令可以配置一個連接發(fā)送的請求數(shù)，其默認(rèn)值為1，表示Tengine完成1次請求后即關(guān)閉連接。

Syntax: check_status [html|csv|json] Default: check_status html Context: location #顯示服務(wù)器的健康狀態(tài)頁面。該指令需要在http塊中配置。在Tengine-1.4.0以后，可以配置顯示頁面的格式。支持的格式有: html、csv、 json。默認(rèn)類型是html。

　配置時需注意：

　　1）type：由于默認(rèn)的type是tcp類型，因此假設(shè)服務(wù)啟動，不管是否初始化完畢，它的端口都會起來，所以此時前段負(fù)載均衡器為認(rèn)為該服務(wù)已經(jīng)可用，其實是不可用狀態(tài)。

　　2）check_http_send：默認(rèn)值是"GET / HTTP/1.0rnrn" 假設(shè)應(yīng)用是通過http://ip/name訪問的，那么這里check_http_send值就需要更改為 "GET /name HTTP/1.0rnrn"才可以。

　　　　針對采用長連接進(jìn)行檢查的， 增加 keep-alive請求 頭，即"HEAD /name HTTP/1.1rnConnection: keep-alivernrn"。

　　　　如果后端的tomcat是基于域名的多虛擬機，此時需要通過 check_http_send定義host，不然每次訪問都是失敗，范例：check_http_send "GET /test HTTP/1.0rn HOST wwwnginx.comrnrn";

三、ngx_http_healthcheck_module

　官方在早期的時候提供的用來進(jìn)行nginx后端節(jié)點的健康檢查，nginx_upstream_check_module模塊就是參照該模塊的設(shè)計理念進(jìn)行開發(fā)的，因此在使用和效果上都大同小異。

　ngx_http_healthcheck_module模塊僅僅支持nginx的1.0.0版本，1.1.0版本以后都不支持了，這里不做闡述。

相關(guān)知識

nginx之健康檢查
nginx中健康檢查(health
Nginx被動健康檢查和主動健康檢查
十大創(chuàng)造性環(huán)保理念：生活在垃圾之中
負(fù)載均衡SLB四層（TCP/UDP）健康檢查出現(xiàn)異常的解決方法
SQLSTATE[08004] [1040] Too many connections
SQLSTATE[HY000] [1040] Too many connections
SQLSTATE[HY000] [2002] Cannot assign requested address
39減肥社區(qū)jianfei.39.net
薄荷健康網(wǎng)bh5.com

網(wǎng)址: Nginx http://m.u1s5d6.cn/newsview400729.html