nginx的重試機制

2022-02-27 14:45:07 字數 3884 閱讀 2311

現在對外服務的**,很少只使用乙個服務節點,而是部署多台伺服器,上層通過一定機制保證容錯和負載均衡。

nginx就是常用的一種http和反向**伺服器,支援容錯和負載均衡。

nginx的重試機制就是容錯的一種。

在nginx的配置檔案中,proxy_next_upstream項定義了什麼情況下進行重試,官網文件中給出的說明如下:

上面的配置表示,如果後端伺服器如下情況,將會把請求**到下一台後端伺服器上。

預設情況下,當請求伺服器發生錯誤或超時時,會嘗試到下一台伺服器。

還有乙個引數影響了重試的次數:proxy_next_upstream_tries,官方文件中給出的說明如下:

該配置決定了最多重試多少次,0表示不限制。

不了解這個機制,在日常開發web服務的時候,就可能會踩坑。

比如有這麼乙個場景:乙個用於匯入資料的web頁面,上傳乙個excel,通過讀取、處理excel,向資料庫中插入資料,處理時間較長(如1分鐘),且為同步操作(即處理完成後才返回結果)。暫且不論這種方式的好壞,若nginx配置的響應等待時間(proxy_read_timeout)為30秒,就會觸發超時重試,將請求又打到另一台。如果處理中沒有考慮到重複資料的場景,就會發生資料多次重複插入!(當然,這種場景,內網可以通過機器名訪問該伺服器進行操作,就可以繞過nginx了,不過外網就沒辦法了。)

同理,在處理post請求的時候也需要注意類似的問題。網上有一篇討論如何阻止post請求的超時重試,感興趣的可以看看點選開啟鏈結

client_header_timeout

語法 client_header_timeout time

預設值 60s

上下文 http server

說明 指定等待client傳送乙個請求頭的超時時間(例如:get / http/1.1).僅當在一次read中,沒有收到請求頭,才會算成超時。如果在超時時間內,client沒傳送任何東西,nginx返回http狀態碼408(「request timed out」)

client_body_timeout

語法 client_body_timeout time

預設值 60s

上下文 http server location

說明 該指令設定請求體(request body)的讀超時時間。僅當在一次readstep中,沒有得到請求體,就會設為超時。超時後,nginx返回http狀態碼408(「request timed out」)

keepalive_timeout

語法 keepalive_timeout timeout [ header_timeout ]

預設值 75s

上下文 http server location

說明 第乙個引數指定了與client的keep-alive連線超時時間。伺服器將會在這個時間後關閉連線。可選的第二個引數指定了在響應頭keep-alive: timeout=time中的time值。這個頭能夠讓一些瀏覽器主動關閉連線,這樣伺服器就不必要去關閉連線了。沒有這個引數,nginx不會傳送keep-alive響應頭(儘管並不是由這個頭來決定連線是否「keep-alive」)

兩個引數的值可並不相同

注意不同瀏覽器怎麼處理「keep-alive」頭

msie和opera忽略掉"keep-alive: timeout=" header.

msie保持連線大約60-65秒,然後傳送tcp rst

opera永久保持長連線

mozilla keeps the connection alive for n plus about 1-10 seconds.

konqueror保持長連線n秒

lingering_timeout

語法 lingering_timeout time

預設值 5s

上下文 http server location

說明 lingering_close生效後,在關閉連線前,會檢測是否有使用者傳送的資料到達伺服器,如果超過lingering_timeout時間後還沒有資料可讀,就直接關閉連線;否則,必須在讀取完連線緩衝區上的資料並丟棄掉後才會關閉連線。

resolver_timeout

語法 resolver_timeout time 

預設值 30s

上下文 http server location

說明 該指令設定dns解析超時時間

proxy_connect_timeout

語法 proxy_connect_timeout time 

預設值 60s

上下文 http server location

說明 該指令設定與upstream server的連線超時時間,有必要記住,這個超時不能超過75秒。

這個不是等待後端返回頁面的時間,那是由proxy_read_timeout宣告的。如果你的upstream伺服器起來了,但是hanging住了(例如,沒有足夠的執行緒處理請求,所以把你的請求放到請求池裡稍後處理),那麼這個宣告是沒有用的,由於與upstream伺服器的連線已經建立了。

proxy_read_timeout

語法 proxy_read_timeout time 

預設值 60s

上下文 http server location

說明 該指令設定與**伺服器的讀超時時間。它決定了nginx會等待多長時間來獲得請求的響應。這個時間不是獲得整個response的時間,而是兩次reading操作的時間。

proxy_send_timeout

語法 proxy_send_timeout time 

預設值 60s

上下文 http server location

說明 這個指定設定了傳送請求給upstream伺服器的超時時間。超時設定不是為了整個傳送期間,而是在兩次write操作期間。如果超時後,upstream沒有收到新的資料,nginx會關閉連線

proxy_upstream_fail_timeout(fail_timeout)

語法 server address [fail_timeout=30s]

預設值 10s

上下文 upstream

說明 upstream模組下 server指令的引數,設定了某乙個upstream後端失敗了指定次數(max_fails)後,該後端不可操作的時間,預設為10秒

websocket 1分鐘會自動斷開問題

location 中的proxy_read_timeout 預設60s斷開,可以把他設定大一點  

原文:

Nginx 失敗重試機制 詳細

nginx 的失敗重試,就是為了實現對客戶端透明的伺服器高可用。然而這部分失敗重試機制比較複雜且官方文件沒詳細介紹,本文將對其解析,並配合實際場景例子使之更容易被理解。這部分介紹最常見 最基礎的失敗重試場景。為了方便理解,使用了以下配置進行分析 proxy next upstream沒有特殊配置 u...

中斷重試機制

原文 中斷重試 中斷重試機制 public abstract class retrytemplate public retrytemplate setsleeptime int sleeptime this sleeptime sleeptime return this public intgetr...

Spring重試機制

org.springframework.retrygroupid spring retryartifactid dependency org.springframework.bootgroupid spring boot starter aopartifactid dependency 程式啟動類新...