通常我們會使用nginx的ngx_http_upstream_module模組來配置伺服器組，示例如下
upstream springboot
server
}在30s內（fail_timeout，預設值為10s），與服務端通訊失敗2次（max_fails，預設值為1，設定為0則認為服務端一直可用），則認為伺服器不可用
不可用伺服器在30s內與服務端通訊成功2次，則認為伺服器恢復
特別需要注意的是，何為與服務端通訊失敗是由upstream的使用方定義的（ngx_http_proxy_module、proxy_next_upstream、fastcgi_next_upstream和memcached_next_upstream）
以proxy_next_upstream為例：
與服務端建立連線、向服務端傳送請求或者解析服務端響應頭時，發生異常或超時將被認為是通訊失敗
服務端返回的響應為空或不合法將被認為是通訊失敗
如果配置了http_500，http_502，http_503，http_504和http_429，服務端返回這些狀態碼將被認為是通訊失敗
服務端返回http_403和http_404永遠不會被認為通訊失敗
當upstream中的一台伺服器響應失敗時， nginx會將請求**給下一台伺服器，直到所有的伺服器都傳送過該請求，如果此時依然無法獲得成功的響應，客戶端將收到最後一台伺服器返回的響應結果
使用上面的配置進行測試：
1 無法主動感知伺服器狀態
2 配置不靈活，無法自定義通訊失敗判斷條件（僅提供少數定義好的狀態碼可供使用）
ngx_http_upstream_hc_module允許週期性的對伺服器組中的伺服器進行健康檢查，前提條件是伺服器組中的伺服器必須使用共享記憶體模式（共享記憶體用來儲存伺服器組的配置資訊以及執行時狀態，nginx的woker程序將共享該配置和狀態），示例如下：
# hc可以通過自定義的校驗規則判斷伺服器狀態
location /
}# 如果配置了多個條件，所有條件均滿足伺服器狀態才被認為是正常的
# 響應狀態碼為200，且響應body中包含"welcome to nginx!"伺服器狀態才被認為是正常的
# nginx僅檢查響應body中的前256k資料
match welcome
}功能十分強大，遺憾的是只有nginx商業版才包含該模組
2，nginx_upstream_check_module
這個模組是由**團隊開發的，並且是完全開源的：nginx_upstream_check_module
**tengine自帶該模組，如果我們沒有使用tengine，可以通過打補丁的方式把該模組加到我們自己的nginx中
sean@ubuntu:~$ unzip nginx_upstream_check_module-master.zip
sean@ubuntu:~$ cd nginx-1.14.0/
# 打補丁
sean@ubuntu:~/nginx-1.14.0$ patch -p1 < ../nginx_upstream_check_module-master/check_1.12.1+.patch
# 新增心跳檢測模組後重新編譯
sean@ubuntu:~/nginx-1.14.0$ sudo ./configure --add-module=../nginx_upstream_check_module-master/
sean@ubuntu:~/nginx-1.14.0$ sudo make
# 備份舊檔案
sean@ubuntu:~/nginx-1.14.0$ sudo mv /usr/local/nginx/sbin/nginx /usr/local/nginx/sbin/nginx.bak
# 使用新檔案
sean@ubuntu:~/nginx-1.14.0$ sudo cp ./objs/nginx /usr/local/nginx/sbin/
sean@ubuntu:~/nginx-1.14.0$ sudo /usr/local/nginx/sbin/nginx -t
nginx: the configuration file /usr/local/nginx/conf/nginx.conf syntax is ok
nginx: configuration file /usr/local/nginx/conf/nginx.conf test is successful
修改nginx配置，官方文件參考：ngx_http_upstream_check_module document
後端伺服器健康檢查狀態都存於共享記憶體中，該指令可以設定共享記憶體的大小，如果伺服器數量較大，需要注意該設定是否夠用
語法：check_shm_size size
預設值：1m
上下文：http
健康檢查規則配置
語法：check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true | false]
預設值：check interval=30000 fall=5 rise=2 timeout=1000 default_down=true type=tcp
上下文：upstream
interval：向後端傳送的健康檢查的間隔時間
fall(fall_count): 連續失敗次數達到fall_count，伺服器被認為是down狀態
rise(rise_count): 連續成功次數達到rise_count，伺服器被認為是up狀態
timeout: 健康檢查請求超時時間
default_down: 設定初始時伺服器的狀態，如果是true，伺服器預設是down狀態，如果是false，伺服器預設是up狀態，預設值是true，也就是一開始伺服器被認為不可用，要等健康檢查請求達到一定成功次數以後才會被認為是健康的
type：健康檢查請求協議型別，支援tcp，http，ssl_hello，mysql和ajp
port：健康檢查請求傳送埠，可以與後端伺服器服務埠不同
乙個連線可傳送的請求數，預設值為1，表示完成1次請求後即關閉連線
語法：check_keepalive_requests request_num
預設值：1
上下文：upstream
http介面健康檢查傳送的請求內容，為了減少傳輸資料量，推薦採用head方法
語法：check_http_send http_packet
預設值："get / http/1.0\r\n\r\n"
上下文：upstream
http介面健康檢查成功狀態碼
語法：check_http_expect_alive [http_2xx | http_3xx | http_4xx | http_5xx]
預設值：http_2xx | http_3xx
上下文：upstream
後端伺服器狀態查詢頁面，提供三種展示方式
語法：check_status [html | csv | json]
預設值：check_status html
上下文：location
------------2018-11-29------------
線上環境檢測的worker機使用tomcat作為容器，check_http_send需要配置host（僅需配置即可，值是否正確不重要），否則會一直傳送心跳檢測，但是一直判定檢測失敗，示例如下：
upstream bj
Nginx 健康檢查
nginx 的健康檢查這塊筆者在網上看了很多文章，基本都是零零散散的，講各種實現方式，沒有一篇能完整的講當下的 nginx 實現健康檢查的幾種方式，應該選哪一種來使用，於是筆者想總結一篇。一 目前 nginx 支援兩種主流的健康檢查模式 主動檢查模式 nginx 服務端會按照設定的間隔時間主動向後端...
nginx 健康檢查
upstream backend 處理過程 1 nginx 在 請求過程中會自動的監測每個後端伺服器對請求的響應狀態，如果某個後端伺服器對請求的響應狀態在短時間內累計一定失敗次數時，nginx 將會標記該伺服器異 常。就不會 流量給該伺服器。不過每間隔一段時間 nginx 還是會 少量的一些請求給該...
Nginx被動健康檢查和主動健康檢查
1.被動健康檢查 nginx自帶有健康檢查模組 ngx http upstream module，可以做到基本的健康檢查，配置如下 upstream cluster server nginx只有當有訪問時後，才發起對後端節點探測。如果本次請求中，節點正好出現故障，nginx依然將請求轉交給故障的節點...