站長(zhǎng)資訊網(wǎng)nginx 是優(yōu)秀的反向代理服務(wù)器，這里主要講它的健康檢查和負(fù)載均衡機(jī)制，以及這種機(jī)制帶來(lái)的問(wèn)題。所謂健康檢查，就是當(dāng)后端出現(xiàn)問(wèn)題（具體什么叫出現(xiàn)問(wèn)題，依賴(lài)于具體實(shí)現(xiàn)，各個(gè)實(shí)現(xiàn)定義不一樣），不再往這個(gè)后端分發(fā)請(qǐng)求，并且做后續(xù)的檢查，直到這個(gè)后端恢復(fù)正常。所謂負(fù)載均衡，就是選擇后端的方式，如何（根據(jù)后端的能力）將請(qǐng)求均衡的分發(fā)到后端。此外，當(dāng)請(qǐng)求某個(gè)后端失敗時(shí)，要將該請(qǐng)求分發(fā)到其它后端（redispatch）。這里以ngx_http_upstream_round_robin（簡(jiǎn)稱(chēng)RR）做為負(fù)載均衡模塊，以ngx_http_proxy_module（檢查proxy）作為后端代理模塊。
nginx 的健康檢查和負(fù)載均衡是密切相關(guān)的，它沒(méi)有獨(dú)立的健康檢查模塊，而是使用業(yè)務(wù)請(qǐng)求作為健康檢查，這省去了獨(dú)立健康檢查線(xiàn)程，這是好處。壞處是，當(dāng)業(yè)務(wù)復(fù)雜時(shí)，可能出現(xiàn)誤判，例如后端響應(yīng)超時(shí)，這是可能是后端宕機(jī)，也可能是某個(gè)業(yè)務(wù)請(qǐng)求自身出現(xiàn)問(wèn)題，跟后端無(wú)關(guān)。如果后端宕機(jī)，nginx還要在將它標(biāo)記為不可用之后，仍不時(shí)的將業(yè)務(wù)請(qǐng)求分發(fā)給它，以檢查后端是否恢復(fù)。
nginx 完成客戶(hù)端請(qǐng)求Header部分的解析，upstream 調(diào)用RR模塊的peer.get 選擇具體的后端。當(dāng)請(qǐng)求結(jié)束，upstream 調(diào)用RR模塊的peer.free，向RR反饋后端的健康情況。當(dāng)upstream和后端通信時(shí)，出現(xiàn)錯(cuò)誤會(huì)調(diào)用 ngx_http_upstream_next，
void ngx_http_upstream_next(ngx_http_request_t *r, ngx_http_upstream_t *u, ngx_uint_t ft_type); 第三個(gè)參數(shù)指明錯(cuò)誤類(lèi)型，共有如下錯(cuò)誤類(lèi)型
#define NGX_HTTP_UPSTREAM_FT_ERROR 0x00000002
#define NGX_HTTP_UPSTREAM_FT_TIMEOUT 0x00000004
#define NGX_HTTP_UPSTREAM_FT_INVALID_HEADER 0x00000008
#define NGX_HTTP_UPSTREAM_FT_HTTP_500 0x00000010
#define NGX_HTTP_UPSTREAM_FT_HTTP_502 0x00000020
#define NGX_HTTP_UPSTREAM_FT_HTTP_503 0x00000040
#define NGX_HTTP_UPSTREAM_FT_HTTP_504 0x00000080
#define NGX_HTTP_UPSTREAM_FT_HTTP_404 0x00000100
#define NGX_HTTP_UPSTREAM_FT_UPDATING 0x00000200
#define NGX_HTTP_UPSTREAM_FT_BUSY_LOCK 0x00000400
#define NGX_HTTP_UPSTREAM_FT_MAX_WAITING 0x00000800
#define NGX_HTTP_UPSTREAM_FT_NOLIVE 0x40000000
ngx_http_upstream_next，只要錯(cuò)誤類(lèi)型不是 NGX_HTTP_UPSTREAM_FT_HTTP_404，都認(rèn)為后端有問(wèn)題（NGX_PEER_FAILED）
if (ft_type == NGX_HTTP_UPSTREAM_FT_HTTP_404) {
state = NGX_PEER_NEXT;
} else {
state = NGX_PEER_FAILED;
}
ngx_http_upstream_next 調(diào)用RR的peer.free，RR根據(jù)state判斷剛才接受請(qǐng)求的后端是否健康。
if (ft_type != NGX_HTTP_UPSTREAM_FT_NOLIVE) {
u->peer.free(&u->peer, u->peer.data, state);
}
ngx_http_upstream_next 如果超過(guò)最大重試次數(shù)（默認(rèn)為后端的個(gè)數(shù)，每試過(guò)一個(gè)，就減1），或者proxy設(shè)置不允許redispatch，則向客戶(hù)端返回響應(yīng)status。
if (u->peer.tries == 0 || !(u->conf->next_upstream & ft_type)) {
ngx_http_upstream_finalize_request(r, u, status);
}
proxy 模塊的 proxy_next_upstream 配置，在何種情況下將請(qǐng)求redispatch到下一個(gè)后端。
剛剛談到，只要錯(cuò)誤類(lèi)型不是 NGX_HTTP_UPSTREAM_FT_HTTP_404，都認(rèn)為后端有問(wèn)題。這里的錯(cuò)誤類(lèi)型包括，連接后端失敗，連接，讀寫(xiě)后端超時(shí)，后端返回了500，502，504等。這個(gè)策略是有待商榷的，尤其是讀寫(xiě)后端超時(shí)也判斷為后端不可用。因?yàn)槟硞€(gè)業(yè)務(wù)請(qǐng)求，可能因?yàn)樽陨淼脑蚨鴮?dǎo)致讀寫(xiě)超時(shí)。注意，在proxy_next_upstream 中指定timeout，http_504 是不同的，前者表示upstream連接，讀寫(xiě)后端超時(shí)，后者表示后端返回的http code 是504。
實(shí)際上健康檢查不是必須的，因?yàn)閞edispatch的存在保證了，就算有后端宕機(jī)，客戶(hù)端仍將收到正確的響應(yīng)。那么我們考慮關(guān)掉健康檢查。通過(guò)upstream 的server配置的max_fails 參數(shù)
RR 的peer.get，如果max_fails 為0，則該后端總是可用的（就算它真有問(wèn)題）。
if (peer->max_fails == 0
|| peer->fails < peer->max_fails)
{
break;
}
因?yàn)閞edispatch的次數(shù)，取決于后端的個(gè)數(shù)，所以后端的個(gè)數(shù)稍微多一點(diǎn)是有好處的。
下面是一些佐證分析的測(cè)試。
upstream test {
server 127.0.0.1:8060 max_fails=0;
server 127.0.0.1:8070 max_fails=0;
server 127.0.0.1:8080 max_fails=0;
server 127.0.0.1:8090 max_fails=0;
}
只有8060，8070是存活的，8080，8090處于不可用狀態(tài)，這里max_fails=0，關(guān)閉了健康檢查。
proxy_read_timeout 2;
讀超時(shí)設(shè)為2S。
proxy_next_upstream error timeout;
默認(rèn)當(dāng) error 和 timeout發(fā)生時(shí)，redispatch。
測(cè)試請(qǐng)求的sleep參數(shù)指定后端的sleep時(shí)間，code參數(shù)指定后端返回的http code。根據(jù)time和sleep時(shí)間的對(duì)比，判斷重試了幾個(gè)后端。
time curl “http://127.0.0.1:8099/index.php?sleep=3” -vv
real 0m4.014s
sleep=3，讀超時(shí)，重試了2個(gè)后端。
修改配置 proxy_next_upstream error;
time curl “http://127.0.0.1:8099/index.php?sleep=3” -vv
real 0m2.018s
讀超時(shí)，不再redispatch，重試了1個(gè)后端。
修改配置 proxy_next_upstream error http_504;
time curl “http://127.0.0.1:8099/index.php?sleep=1” -vv
real 0m1.022s
這個(gè)是正常請(qǐng)求。
time curl “http://127.0.0.1:8099/index.php?sleep=1&code=504” -vv
real 0m2.023s
讓后端返回504，此時(shí)nginx會(huì)做redispatch，重試了2個(gè)后端
但是nginx返回給客戶(hù)端的是502，不是504，因?yàn)樗械暮蠖硕挤祷?04，nginx認(rèn)為后端不可用，返回502.
測(cè)試健康檢查，關(guān)掉redispatch。proxy_next_upstream off;
curl “http://127.0.0.1:8099/index.php?sleep=3” -vv
返回了兩次502，兩次504。存活的后端返回504，有問(wèn)題的返回502。
修改 max_fails server 127.0.0.1:8060 max_fails=1; 對(duì)8060開(kāi)啟健康檢查。
curl “http://127.0.0.1:8099/index.php?sleep=3” -vv
第一輪4次請(qǐng)求，返回兩次502，兩次504
8080和8090有問(wèn)題，返回502，8060和8070響應(yīng)超時(shí)，返回504，因?yàn)?060開(kāi)啟了健康檢查，并且返回了504，所以被標(biāo)記為不可用。
第二輪4次請(qǐng)求，返回三次502，一次504。8070沒(méi)有開(kāi)啟健康檢查，所以仍然返回504。
根據(jù)測(cè)試分析，業(yè)務(wù)請(qǐng)求（sleep 3s，或者 輸出 http 504）可以讓nginx誤以為后端宕了，而這時(shí)后端活得好好的。在私有云平臺(tái)，這個(gè)通常不是問(wèn)題，把超時(shí)設(shè)大點(diǎn)，不返回5XX錯(cuò)誤，可以避免這個(gè)問(wèn)題。但是在公有云平臺(tái)，這是致命的，因?yàn)闃I(yè)務(wù)可以編程輸出5XX錯(cuò)誤。有兩種方法應(yīng)對(duì)，一種是關(guān)閉健康檢查，一種是修改nginx的代碼，僅對(duì) NGX_HTTP_UPSTREAM_FT_ERROR 判定為后端有問(wèn)題。
