nginx 健康檢查

2022-06-21 03:36:08 字數 790 閱讀 2151

upstream backend

處理過程

1、nginx 在**請求過程中會自動的監測每個後端伺服器對請求的響應狀態,如果某個後端伺服器對請求的響應狀態在短時間內累計一定失敗次數時,nginx 將會標記該伺服器異            常。就不會**流量給該伺服器。 不過每間隔一段時間 nginx 還是會**少量的一些請求給該後端伺服器來探測它的返回狀態。 以便識別該伺服器是否恢復。

後端伺服器不需要專門提供健康檢查介面,不過這種方式會造成一些使用者請求的響應失敗,因為 nginx 需要用一些少量的請求去試探後端的服務是否恢復正常。

2、這樣有乙個缺點是,nginx是被動地進行健康檢查,也就是當有請求過來時,且請求打到a服務上時才能得知a服務的狀態,如果a服務異常還要**一次,效率受到影響。

安裝nginx_upstream_check_module

location /

upstream cluster

引數詳解:

interval: 向後端傳送的健康檢查包的間隔,單位為毫秒

rsie: 如果連續成功次數達到rise_count,伺服器就被認為是up

fall: 如果連續失敗次數達到fall_count,伺服器就被認為是down

timeout: 後端健康請求的超時時間,單位為毫秒

type: 健康檢查包的型別,支援tcp、ssl_hello、http、mysql、ajp

tips

這種是主動模式,根據配置頻率定期檢查達到判斷條件就做出判定。需要nginx 開通額外的介面,有一點資源開銷。

Nginx 健康檢查

nginx 的健康檢查這塊筆者在網上看了很多文章,基本都是零零散散的,講各種實現方式,沒有一篇能完整的講當下的 nginx 實現健康檢查的幾種方式,應該選哪一種來使用,於是筆者想總結一篇。一 目前 nginx 支援兩種主流的健康檢查模式 主動檢查模式 nginx 服務端會按照設定的間隔時間主動向後端...

nginx健康檢查

通常我們會使用nginx的ngx http upstream module模組來配置伺服器組,示例如下 upstream springboot server 在30s內 fail timeout,預設值為10s 與服務端通訊失敗2次 max fails,預設值為1,設定為0則認為服務端一直可用 則認...

Nginx被動健康檢查和主動健康檢查

1.被動健康檢查 nginx自帶有健康檢查模組 ngx http upstream module,可以做到基本的健康檢查,配置如下 upstream cluster server nginx只有當有訪問時後,才發起對後端節點探測。如果本次請求中,節點正好出現故障,nginx依然將請求轉交給故障的節點...