nginx原生的健康檢測主要涉及兩個模塊:ngx_http_proxy_module和ngx_http_upstream_module
一、ngx_http_upstream_module模塊
upstream backend {
server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
}
1.max_fails
設定Nginx與服務器通信的嘗試失敗的次數。在fail_timeout參數定義的時間段內，如果失敗的次數達到此值，Nginx就認爲服務器不可用。在下一個fail_timeout時間段，服務器不會再被嘗試。 失敗的嘗試次數默認是1。設爲0就會停止統計嘗試次數，認爲服務器是一直可用的。 你可以通過指令proxy_next_upstream、fastcgi_next_upstream和 memcached_next_upstream來配置什麼是失敗的嘗試。 默認配置時，http_404狀態不被認爲是失敗的嘗試。
2.fail_timeout
設定服務器被認爲不可用的時間段以及統計失敗嘗試次數的時間段。在這段時間中，服務器失敗次數達到指定的嘗試次數，服務器就被認爲不可用。默認情況下，該超時時間是10秒。
二、ngx_http_proxy_module模塊
1.proxy_connect_timeout
與後端服務器建立連接的超時時間
2.proxy_read_timeout
定義從後端服務器讀取響應的超時。此超時是指相鄰兩次讀操作之間的最長時間間隔，而不是整個響應傳輸完成的最長時間。如果後端服務器在超時時間段內沒有傳輸任何數據，連接將被關閉
3.proxy_next_upstream
指定在何種情況下一個失敗的請求應該被髮送到下一臺後端服務器
需要理解一點的是，只有在沒有向客戶端發送任何數據以前，將請求轉給下一臺後端服務器纔是可行的。也就是說，如果在傳輸響應到客戶端時出現錯誤或者超時，這類錯誤是不可能恢復的。
三、原生nginx的健康檢測存在的問題
1.節點異常：如果後端節點異常，nginx依然會先把該請求轉發給該異常節點，然後再轉發給別的節點，這樣就會浪費一次轉發。當嘗試max_fails次失敗後纔會將其設置爲異常節點。
2.無法精確判斷異常節點是否恢復：判斷爲異常的節點，在fail_timeout時間後，nginx直接使用線上流量去請求異常節點，而不是先探測是否恢復，在導入線上流量
四、使用第三方健康檢測模塊nginx_upstream_check_module
使用第三方檢測模塊可以很好的解決上述問題。
在編譯了nginx_upstream_check_module模塊後，可以在upstream中定義。
check interval=milliseconds [fall=count] [rise=count] [timeout=milliseconds] [default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp]
- interval：向後端發送的健康檢查包的間隔。
- fall(fall_count): 如果連續失敗次數達到fall_count，服務器就被認爲是down。
- rise(rise_count): 如果連續成功次數達到rise_count，服務器就被認爲是up。
- timeout: 後端健康請求的超時時間。
- default_down: 設定初始時服務器的狀態，如果是true，就說明默認是down的，如果是false，就是up的。默認值是true，也就是一開始服務器認爲是不可用，要等健康檢查包達到一定成功次數以後纔會被認爲是健康的。
- type：健康檢查包的類型，現在支持以下多種類型
- tcp：簡單的tcp連接，如果連接成功，就說明後端正常。
- ssl_hello：發送一個初始的SSL hello包並接受服務器的SSL hello包。
- http：發送HTTP請求，通過後端的回覆包的狀態來判斷後端是否存活。
- mysql: 向mysql服務器連接，通過接收服務器的greeting包來判斷後端是否存活。
- ajp：向後端發送AJP協議的Cping包，通過接收Cpong包來判斷後端是否存活。
- port: 指定後端服務器的檢查端口。你可以指定不同於真實服務的後端服務器的端口，比如後端提供的是443端口的應用，你可以去檢查80端口的狀態來判斷後端健康狀況。默認是0，表示跟後端server提供真實服務的端口一樣。