前言
nginx做負載均衡性能很好，但是負載中的節點有異常怎么處理呢？
當然是nginx發現某一個節點為異常節點后自動將請求轉移至其他節點直至轉移到一個正常節點。
為了實現這一步有如下兩個解決方案可供選擇，推薦方案一（不需要安裝module😄）。
下面進行兩個解決方案的詳細贅述。
一、使用nginx的upstream自帶屬性進行配置
配置示例
upstream circle_server { ... server 192.168.0.88:8080 max_fails=1 fail_timeout=10; ... }
默認：fail_timeout為10s,max_fails為1次。
原理解析：
max_fails=3 fail_timeout=30s代表在30秒內請求某一應用失敗3次，認為該應用宕機，后等待30秒，這期間內不會再把新請求發送到宕機應用，而是直接發到正常的那一台，時間到后再有請求進來繼續嘗試連接宕機應用且僅嘗試1次，如果還是失敗，則繼續等待30秒...以此循環，直到恢復。
同時，upstream還有其他屬性，見文章尾部。
二、使用nginx_upstream_check_module模塊進行負載監測
1.官方地址
https://github.com/yaoweibin/nginx_upstream_check_module
2.安裝nginx_upstream_check_module模塊
系統如果已經安裝nginx，則需要采取打補丁的方式安裝該模塊
查看安裝版本
/application/nginx/sbin/nginx -v
下載補丁包
wget https://codeload.github.com/yaoweibin/nginx_upstream_check_module/zip/master
解壓下載的補丁包
unzip master
重新編譯nginx
因為是對nginx打補丁，需要對應安裝版本的軟件包
cd nginx-1.15.12 patch -p1 < ../nginx_upstream_check_module-master/check_1.14.0+.patch
編譯參數要和以前一樣，最后加上 --add-module=…/nginx_upstream_check_module-master/
./configure --user=www --group=www --prefix=/application/nginx-1.15.2 --with-http_ssl_module --with-http_gzip_static_module --with-http_stub_status_module --add-module=../nginx_upstream_check_module-master/
安裝
make && make install
配置
http { upstream dynamic_pools { server192.168.10.30; server192.168.10.31; check interval=3000 rise=2 fall=5timeout=1000; # interval檢測間隔時間，單位為毫秒，rsie請求2次正常的話，標記此realserver的狀態為up，fall表示請求5次都失敗的情況下，標記此realserver的狀態為down，timeout為超時時間，單位為毫秒。 } server { listen 80; server_name www.etiantian.org; location / { proxy_pass http://dynamic_pools; includeproxy.conf; } location /nstatus { check_status; access_log off; #不記錄訪問日志 allow192.168.10.0/24; #允許的ip地址（段） deny all; #除過允許的ip地址（段）拒絕所有ip訪問 } } }
3. upstream_check_module語法
Syntax: checkinterval=milliseconds [fall=count] [rise=count] [timeout=milliseconds][default_down=true|false] [type=tcp|http|ssl_hello|mysql|ajp] [port=check_port]
Default: 如果沒有配置參數，默認值是：interval=30000 fall=5rise=2 timeout=1000 default_down=true type=tcp
Context: upstream
指令后面的參數意義是：
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提供真實服務的端口一樣。該選項出現於Tengine-1.4.0。
三、upstream知識擴充
upstream 參數
nginx關於upstream參數官方文檔：http://nginx.org/en/docs/http/ngx_http_upstream_module.html
server
每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器down掉，能自動剔除 配置如下:
upstream names{
server 127.0.0.1:8050 ;
server 127.0.0.1:8060 ;
}
weight(權重)
指定輪詢幾率，weight和訪問比率成正比，用於后端服務器性能不均的情況。
upstream tuling {
server 127.0.0.1:8050 weight=5;
server 127.0.0.1:8060 weight=1;
}
max_conns
可以根據服務的好壞來設置最大連接數，防止掛掉，比如1000，我們可以設置800
upstream tuling {
server 127.0.0.1:8050 weight=1 max_fails=1 fail_timeout=20;
server 127.0.0.1:8060 weight=1;
}
max_fails、 fail_timeout
max_fails:失敗多少次 認為主機已掛掉則，踢出，公司資源少的話一般設置2~3次，多的話設置1次
max_fails=3 fail_timeout=30s代表在30秒內請求某一應用失敗3次，認為該應用宕機，后等待30秒，這期間內不會再把新請求發送到宕機應用，而是直接發到正常的那一台，時間到后再有請求進來繼續嘗試連接宕機應用且僅嘗試1次，如果還是失敗，則繼續等待30秒...以此循環，直到恢復。
upstream tuling {
server 127.0.0.1:8050 weight=1 max_fails=1 fail_timeout=20;
server 127.0.0.1:8060 weight=1;
}
//關閉掉8050的服務 你會發現在20秒內還是訪問8060的，20s后才會訪問8050
記得修改完nginx.conf 后，./sbin/nginx -s reload 重啟nginx ,然后我們可以讓8050關閉來演示
負載均衡算法
輪詢+weight 默認的
ip_hash : 基於Hash 計算
應用場景：保持session 一至性
url_hash: (第三方)
應用場景：靜態資源緩存,節約存儲，加快速度
least_conn 最少鏈接
least_time 最小的響應時間,計算節點平均響應時間，然后取響應最快的那個，分配更高權重。
下面是ip_hash,url_hash的示意圖
下面是nginx大概的參數流程（粗略）
