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     
#設定Nginx與服務器通信的嘗試失敗的次數。在fail_timeout參數定義的時間段內，如果失敗的次數達到此值，Nginx就認為服務器不可用。在下一個fail_timeout時間段，服務器不會再被嘗試。 失敗的嘗試次數默認是1。設為0就會停止統計嘗試次數，認為服務器是一直可用的。 你可以通過指令proxy_next_upstream、fastcgi_next_upstream和 memcached_next_upstream來配置什么是失敗的嘗試。 默認配置時，http_404狀態不被認為是失敗的嘗試。

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

增加檢測次數，及超時時間修復：

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;
    }