Nginx 健康檢查和負載均衡機制分析
nginx 是優秀的反向代理伺服器，這裡主要講它的健康檢查和負載均衡機制，以及這種機制帶來的問題。所謂健康檢查，就是當後端出現問題（具體什麼叫出現問題，依賴於具體實現，各個實現定義不一樣），不再往這個後端分發請求，並且做後續的檢查，直到這個後端恢復正常。所謂負載均衡，就是選擇後端的方式，如何（根據後端的能力）將請求均衡的分發到後端。此外，當請求某個後端失敗時，要將該請求分發到其它後端（redispatch）。這裡以ngx_http_upstream_round_robin（簡稱RR）做為負載均衡模組，以ngx_http_proxy_module（檢查proxy）作為後端代理模組。
nginx 的健康檢查和負載均衡是密切相關的，它沒有獨立的健康檢查模組，而是使用業務請求作為健康檢查，這省去了獨立健康檢查執行緒，這是好處。壞處是，當業務複雜時，可能出現誤判，例如後端響應超時，這是可能是後端宕機，也可能是某個業務請求自身出現問題，跟後端無關。如果後端宕機，nginx還要在將它標記為不可用之後，仍不時的將業務請求分發給它，以檢查後端是否恢復。
nginx 完成客戶端請求Header部分的解析，upstream 呼叫RR模組的peer.get 選擇具體的後端。當請求結束，upstream 呼叫RR模組的peer.free，向RR反饋後端的健康情況。當upstream和後端通訊時，出現錯誤會呼叫 ngx_http_upstream_next，
void ngx_http_upstream_next(ngx_http_request_t *r, ngx_http_upstream_t *u, ngx_uint_t ft_type); 第三個引數指明錯誤型別，共有如下錯誤型別
#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，只要錯誤型別不是 NGX_HTTP_UPSTREAM_FT_HTTP_404，都認為後端有問題（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 呼叫RR的peer.free，RR根據state判斷剛才接受請求的後端是否健康。
if (ft_type != NGX_HTTP_UPSTREAM_FT_NOLIVE) {
u->peer.free(&u->peer, u->peer.data, state);
}
ngx_http_upstream_next 如果超過最大重試次數（預設為後端的個數，每試過一個，就減1），或者proxy設定不允許redispatch，則向客戶端返回響應status。
if (u->peer.tries == 0 || !(u->conf->next_upstream & ft_type)) {
ngx_http_upstream_finalize_request(r, u, status);
}
proxy 模組的 proxy_next_upstream 配置，在何種情況下將請求redispatch到下一個後端。
剛剛談到，只要錯誤型別不是 NGX_HTTP_UPSTREAM_FT_HTTP_404，都認為後端有問題。這裡的錯誤型別包括，連線後端失敗，連線，讀寫後端超時，後端返回了500，502，504等。這個策略是有待商榷的，尤其是讀寫後端超時也判斷為後端不可用。因為某個業務請求，可能因為自身的原因而導致讀寫超時。注意，在proxy_next_upstream 中指定timeout，http_504 是不同的，前者表示upstream連線，讀寫後端超時，後者表示後端返回的http code 是504。
實際上健康檢查不是必須的，因為redispatch的存在保證了，就算有後端宕機，客戶端仍將收到正確的響應。那麼我們考慮關掉健康檢查。通過upstream 的server配置的max_fails 引數
RR 的peer.get，如果max_fails 為0，則該後端總是可用的（就算它真有問題）。
if (peer->max_fails == 0
|| peer->fails < peer->max_fails)
{
break;
}
因為redispatch的次數，取決於後端的個數，所以後端的個數稍微多一點是有好處的。
下面是一些佐證分析的測試。
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處於不可用狀態，這裡max_fails=0，關閉了健康檢查。
proxy_read_timeout 2;
讀超時設為2S。
proxy_next_upstream error timeout;
預設當 error 和 timeout發生時，redispatch。
測試請求的sleep引數指定後端的sleep時間，code引數指定後端返回的http code。根據time和sleep時間的對比，判斷重試了幾個後端。
time curl "http://127.0.0.1:8099/index.php?sleep=3" -vv
real 0m4.014s
sleep=3，讀超時，重試了2個後端。
修改配置 proxy_next_upstream error;
time curl "http://127.0.0.1:8099/index.php?sleep=3" -vv
real 0m2.018s
讀超時，不再redispatch，重試了1個後端。
修改配置 proxy_next_upstream error http_504;
time curl "http://127.0.0.1:8099/index.php?sleep=1" -vv
real 0m1.022s
這個是正常請求。
time curl "http://127.0.0.1:8099/index.php?sleep=1&code=504" -vv
real 0m2.023s
讓後端返回504，此時nginx會做redispatch，重試了2個後端
但是nginx返回給客戶端的是502，不是504，因為所有的後端都返回504，nginx認為後端不可用，返回502.
測試健康檢查，關掉redispatch。proxy_next_upstream off;
curl "http://127.0.0.1:8099/index.php?sleep=3" -vv
返回了兩次502，兩次504。存活的後端返回504，有問題的返回502。
修改 max_fails server 127.0.0.1:8060 max_fails=1; 對8060開啟健康檢查。
curl "http://127.0.0.1:8099/index.php?sleep=3" -vv
第一輪4次請求，返回兩次502，兩次504
8080和8090有問題，返回502，8060和8070響應超時，返回504，因為8060開啟了健康檢查，並且返回了504，所以被標記為不可用。
第二輪4次請求，返回三次502，一次504。8070沒有開啟健康檢查，所以仍然返回504。
根據測試分析，業務請求（sleep 3s，或者 輸出 http 504）可以讓nginx誤以為後端宕了，而這時後端活得好好的。在私有云平臺，這個通常不是問題，把超時設大點，不返回5XX錯誤，可以避免這個問題。但是在公有云平臺，這是致命的，因為業務可以程式設計輸出5XX錯誤。有兩種方法應對，一種是關閉健康檢查，一種是修改nginx的程式碼，僅對 NGX_HTTP_UPSTREAM_FT_ERROR 判定為後端有問題。
Linux公社的RSS地址 ：ofollow,noindex" target="_blank">https://www.linuxidc.com/rssFeed.aspx
本文永久更新連結地址：https://www.linuxidc.com/Linux/2018-10/154666.htm