no live upstreams while connecting to upstream

nginx 代理tomcat報錯：

查看日志：

2017/06/07 15:11:32 [error] 29011#0: *376979 no live upstreams while connecting to upstream, client: 11.12.13.14, server: ccc, request: "GET /sdlcrd HTTP/1.1", upstream: "http://sdlcrdBackend/sdlcrd", host: "test-reg.ckl.com:88", referrer: "http://test-reg.ckl.com:88/sdsso/mvc/uipBaseController/showApplication?userCode=1492133480995"
2017/06/07 15:11:32 [error] 29012#0: send() failed (111: Connection refused)
2017/06/07 15:11:36 [error] 29011#0: *376979 no live upstreams while connecting to upstream, client: 11.12.13.14, server: ccc, request: "GET /sdlcrd HTTP/1.1", upstream: "http://sdlcrdBackend/sdlcrd", host: "test-reg.ckl.com:88", referrer: "http://test-reg.ckl.com:88/sdsso/mvc/uipBaseController/showApplication?userCode=1492133480995"
2017/06/07 15:11:37 [error] 29012#0: send() failed (111: Connection refused)

查看nginx upstream配置：

upstream sdlcrdBackend {
        server 192.168.1.74:8080 weight=1 max_fails=2 fail_timeout=30s;
                sticky name=com.ckl.sdlcrd.UAT.route domain=test-reg.ckl.com;
                check interval=5000 rise=2 fall=3 timeout=1000 type=http;
                check_http_send "HEAD / HTTP/1.0\r\n\r\n";
                check_http_expect_alive http_2xx http_3xx;
 }

 說明：

max_fails=number     
#設(shè)定Nginx與服務(wù)器通信的嘗試失敗的次數(shù)。在fail_timeout參數(shù)定義的時間段內(nèi)，如果失敗的次數(shù)達到此值，Nginx就認為服務(wù)器不可用。在下一個fail_timeout時間段，服務(wù)器不會再被嘗試。 失敗的嘗試次數(shù)默認是1。設(shè)為0就會停止統(tǒng)計嘗試次數(shù)，認為服務(wù)器是一直可用的。 你可以通過指令proxy_next_upstream、fastcgi_next_upstream和 memcached_next_upstream來配置什么是失敗的嘗試。 默認配置時，http_404狀態(tài)不被認為是失敗的嘗試。

fail_timeout=time      
#設(shè)定服務(wù)器被認為不可用的時間段以及統(tǒng)計失敗嘗試次數(shù)的時間段。在這段時間中，服務(wù)器失敗次數(shù)達到指定的嘗試次數(shù)，服務(wù)器就被認為不可用。默認情況下，該超時時間是10秒。
 在實際應(yīng)用當(dāng)中，如果你后端應(yīng)用是能夠快速重啟的應(yīng)用，比如nginx的話，自帶的模塊是可以滿足需求的。但是需要注意。如果后端有不健康節(jié)點，負載均衡器依然會先把該請求轉(zhuǎn)發(fā)給該不健康節(jié)點，然后再轉(zhuǎn)發(fā)給別的節(jié)點，這樣就會浪費一次轉(zhuǎn)發(fā)。
可是，如果當(dāng)后端應(yīng)用重啟時，重啟操作需要很久才能完成的時候就會有可能拖死整個負載均衡器。此時，由于無法準確判斷節(jié)點健康狀態(tài)，導(dǎo)致請求handle住，出現(xiàn)假死狀態(tài)，最終整個負載均衡器上的所有節(jié)點都無法正常響應(yīng)請求。由于公司的業(yè)務(wù)程序都是java開發(fā)的，因此后端主要是nginx集群和tomcat集群。由于tomcat重啟應(yīng)部署上面的業(yè)務(wù)不同，有些業(yè)務(wù)啟動初始化時間過長，就會導(dǎo)致上述現(xiàn)象的發(fā)生，因此不是很建議使用該模式。
并且ngx_http_upstream_module模塊中的server指令中的max_fails參數(shù)設(shè)置值，也會和ngx_http_proxy_module 模塊中的的proxy_next_upstream指令設(shè)置起沖突。比如如果將max_fails設(shè)置為0，則代表不對后端服務(wù)器進行健康檢查，這樣還會使fail_timeout參數(shù)失效（即不起作用）。此時，其實我們可以通過調(diào)節(jié)ngx_http_proxy_module 模塊中的 proxy_connect_timeout 指令、proxy_read_timeout指令，通過將他們的值調(diào)低來發(fā)現(xiàn)不健康節(jié)點，進而將請求往健康節(jié)點轉(zhuǎn)移。

增加檢測次數(shù)，及超時時間修復(fù)：

upstream sdlcrdBackend {
        server 192.168.1.74:8080 weight=10 max_fails=2 fail_timeout=60s;
                sticky name=com.ckl.sdlcrd.UAT.route domain=test-reg.ckl.com;
                check interval=5000 rise=2 fall=3 timeout=1000 type=http;
                check_http_send "HEAD / HTTP/1.0\r\n\r\n";
                check_http_expect_alive http_2xx http_3xx;
    }