Nginx之upstream被動式重試機(jī)制的實現(xiàn)
我們使用Nginx通過反向代理做負(fù)載均衡時,如果被代理的其中一個服務(wù)發(fā)生錯誤或者超時的時候,通常希望Nginx自動重試其他的服務(wù),從而實現(xiàn)服務(wù)的高可用性。實際上Nginx本身默認(rèn)會有錯誤重試機(jī)制,并且可以通過proxy_next_upstream來自定義配置。
Nginx 通過 proxy_next_upstream 參數(shù)來定義什么情況下會被認(rèn)為是 fails,從而觸發(fā)失敗重試機(jī)制。
fails 可以分成兩類:
- 默認(rèn)錯誤,包括 error、timeout
- 選擇定義錯誤,包含 invalid_header 以及各種異常 http 狀態(tài)碼錯誤等
默認(rèn)錯誤
出現(xiàn) error 的場景,常見的是上游服務(wù)器的服務(wù)重啟、停止,或者異常崩潰導(dǎo)致的無法提供正常服務(wù)。而 timeout 的情況,就是代理請求過程中達(dá)到對應(yīng)的超時配置,主要包括了:
proxy_connect_timeout,建立三次握手的時間proxy_read_timeout,建立連接后,等待上游服務(wù)器響應(yīng)以及處理請求的時間proxy_send_timeout,數(shù)據(jù)回傳的間隔時間(注意不是數(shù)據(jù)發(fā)送耗時)
選擇定義錯誤
異常狀態(tài)碼部分(就是 4xx、5xx 錯誤)。上游服務(wù)器返回空響應(yīng)或者非法響應(yīng)頭
invalid_header: a server returned an empty or invalid response;
其默認(rèn)值是proxy_next_upstream error timeout,即發(fā)生網(wǎng)絡(luò)錯誤以及超時,才會重試其他服務(wù)器。默認(rèn)情況下服務(wù)返回500狀態(tài)碼是不會重試的
指令配置
proxy_next_upstream
設(shè)置當(dāng)連接upstream服務(wù)器集群中的某個服務(wù)器第一次失敗時,指定在哪些情況下將請求傳遞到下一個服務(wù)器
語法: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | http_429 | non_idempotent | off ...; 默認(rèn): proxy_next_upstream error timeout; 使用位置: http, ,serverlocation
- error # 與服務(wù)器建立連接,向其傳遞請求或讀取響應(yīng)頭時發(fā)生錯誤;
- timeout # 在與服務(wù)器建立連接,向其傳遞請求或讀取響應(yīng)頭時發(fā)生超時;
- invalid_header # 服務(wù)器返回空的或無效的響應(yīng);
- http_500 # 服務(wù)器返回代碼為500的響應(yīng);
- http_502 # 服務(wù)器返回代碼為502的響應(yīng);
- http_503 # 服務(wù)器返回代碼為503的響應(yīng);
- http_504 # 服務(wù)器返回代碼504的響應(yīng);
- http_403 # 服務(wù)器返回代碼為403的響應(yīng);
- http_404 # 服務(wù)器返回代碼為404的響應(yīng);
- http_429 # 服務(wù)器返回代碼為429的響應(yīng)(1.11.13);
- non_idempotent # 通常,請求與 非冪等 方法(POST,LOCK,PATCH)不傳遞到請求是否已被發(fā)送到上游服務(wù)器(1.9.13)的下一個服務(wù)器; 啟用此選項顯式允許重試此類請求;
- off # 禁用將請求傳遞給下一個服務(wù)器。
當(dāng)請求類型是POST時,Nginx默認(rèn)不會失敗重試,如果想讓POST請求也會失敗重試,需要配置non_idempotent。
配置示例:
代碼語言:javascript
upstream nginxretry {
server 127.0.0.1:9030 weight=10;
server 127.0.0.1:9031 weight=10;
}
server {
listen 9039;
location / {
proxy_pass http://nginxretry;
proxy_next_upstream error timeout http_500;
}
}proxy_next_upstream_timeout
設(shè)置重試的超時時間,超時后不再重試,給用戶返回錯誤,默認(rèn)為0,即不做限制
語法: | proxy_next_upstream_timeout time; |
|---|---|
Default: | proxy_next_upstream_timeout 0; |
Context: | http, server, location |
proxy_next_upstream_tries
設(shè)置重試的最大次數(shù),若超過重試次數(shù),也不再重試,默認(rèn)為0,即不做限制(proxy_next_upstream_timeout時間內(nèi)允許proxy_next_upstream_tries次重試,包括第一次)
語法: | proxy_next_upstream_tries number; |
|---|---|
Default: | proxy_next_upstream_tries 0; |
Context: | http, server, location |
配置示例:
server {
proxy_next_upstream error timeout;
proxy_next_upstream_timeout 15s;
proxy_next_upstream_tries 5;
}重試限制方式
默認(rèn)配置是沒有做重試機(jī)制進(jìn)行限制的,也就是會盡可能去重試直至失敗。
Nginx 提供了以下兩個參數(shù)來控制重試次數(shù)以及重試超時時間:
proxy_next_upstream_tries:設(shè)置重試次數(shù),默認(rèn)0表示無限制,該參數(shù)包含所有請求 upstream server 的次數(shù),包括第一次后之后所有重試之和;proxy_next_upstream_timeout:設(shè)置重試最大超時時間,默認(rèn)0表示不限制,該參數(shù)指的是第一次連接時間加上后續(xù)重試連接時間,不包含連接上節(jié)點之后的處理時間
對upstream中某單一服務(wù)器的限制
- max_fails:最大失敗次數(shù)(0為標(biāo)記一直可用,不檢查健康狀態(tài))
- fail_timeout:失敗時間(當(dāng)fail_timeout時間內(nèi)失敗了max_fails次,標(biāo)記服務(wù)不可用fail_timeout時間后會再次激活次服務(wù))
配置示例1:
upstream httpget {
server 192.168.111.101:8080 max_fails=5 fail_timeout=10s;
server 192.168.111.102:8080;
}配置示例2:
proxy_connect_timeout 3s;
proxy_next_upstream_timeout 6s;
proxy_next_upstream_tries 3;
upstream test {
server 127.0.0.1:8001 fail_timeout=60s max_fails=2; # Server A
server 127.0.0.1:8002 fail_timeout=60s max_fails=2; # Server B
server 127.0.0.1:8003 fail_timeout=60s max_fails=2; # Server C
}到此這篇關(guān)于Nginx之upstream被動式重試機(jī)制的實現(xiàn)的文章就介紹到這了,更多相關(guān)Nginx upstream被動式重試機(jī)制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
docker nginx實現(xiàn)一個主機(jī)部署多個站點操作
這篇文章主要介紹了docker nginx實現(xiàn)一個主機(jī)部署多個站點操作,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧2020-11-11
Nginx結(jié)合keepalived實現(xiàn)集群
本文主要介紹了Nginx結(jié)合keepalived實現(xiàn)集群,文中通過示例代碼介紹的非常詳細(xì),對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2024-05-05

