我們都知道nginx可以用作負載均衡可以通過輪訓、weight、ip_hash、url_hash、fair的方式很好的分散請求的壓力。基於nginx阿里也有自己的tengin。
同時nginx可以對故障轉移進行配置，相關的配置項如下所示：
如配置webserver1、webserver2、webserver3 三颱集群，當有請求過來時會根據配置的負載均衡策略進行請求**。如請求a被**到webserver1中，但因為webserver伺服器壓力過大，產生了proxy_next_upstream中配置的現象，如超時未返回資料等現象，便會出發nginx的故障轉移機制，將請求**到其餘伺服器上進行處理。
好處： 保證了集群的高可用
壞處： 頻繁的進行請求**會給集群帶來壓力，甚至造成雪崩。
有乙個傳送簡訊的http服務，客戶端呼叫之後，只有一次請求，但是發了三次簡訊。
分析：
1、客戶端僅發起了一次請求，
2、服務端收到了三次請求
3、三次請求分別落在了三颱後端機器上。每台後端機器僅收到一次請求
分析**，**中沒有重試機制，並且通過請求分布來看，並不是一台機器處理了三次，而是每台機器處理了一次。所以分析，可能是由於nginx**導致。
檢視介面的響應時間，發現每個介面的響應時間為18s左右（ps：由於是呼叫外部介面，此呼叫時間屬於正常的時間。。。）。
猜測是由於後端伺服器未能及時返回資料，導致了nginx的超時重試機器，將請求分發到了另外一台機器上。
檢視nginx的配置檔案，發現如下配置：
proxy_next_upstream http_502 http_504 error timeout invalid_header;
上面的配置表示，如果後端伺服器如下情況，將會把請求**到下一台後端伺服器上。
error - 在連線到乙個伺服器，傳送乙個請求，或者讀取應答時發生錯誤。
timeout - 在連線到伺服器，**請求或者讀取應答時發生超時。
invalid_header - 伺服器返回空的或者錯誤的應答。
http_502 - 伺服器返回502**。
http_504 - 伺服器返回504**。
proxy_read_timeout 15;
超時時間為15s，所以後端伺服器響應慢，nginx沒有在15s內收到返回的資料，所以將請求切換到下一台後端機器了，所以，同樣的情況下， 請求第二台後端機器時，也沒有在規定的時間內得到響應，所以又切換到第三台機器了，最終導致簡訊傳送了三次。
幾個引數說明：
proxy_send_timeout 後端伺服器資料回傳時間(**傳送超時時間)
proxy_read_timeout 連線成功後，後端伺服器響應時間(**接收超時時間)
proxy_connect_timeout nginx連線後端的超時時間，一般不超過75s
如何解決呢？
第一種辦法：因為後端機器無法再進行優化減少響應時間，所以可以更改nginx的超時時間，將原本的15s更改為40s，這樣可以保證結果正常返回。
第二種辦法 ：關閉自動切換到**機器的功能，即將proxy_next_upstream配置為off。但是這樣雖然能解決問題，但是會導致nginx的容錯能力下降。
第三種，最後的才是最香的：
nginx的熔斷機制：
當某台被**伺服器處理請求，出現一定次數的錯誤的情況下，nginx在一定時間內不再將請求分配給這台伺服器進行處理。 過了熔斷時間後，nginx會再次嘗試分配一次請求給該伺服器處理，如果還是失敗，那麼繼續熔斷。
upstream指令塊中server定義的熔斷引數配置：
max_fails = number; # 熔斷機制的錯誤次數 閾值（預設1）
fail_timeout = time #熔斷時間（nginx標記伺服器不可用的持續時間，預設10s）
示例： server 192.168.1.100 max_fails=3 fail_timeout= 10s;
以上現象還可能出現在以下的場景：
1、上傳excel，然後服務端處理excel內容，插入到db裡面的時候，可能存在多次**導致資料重複。
2、post請求處理時間過長，可能出現重複提交的問題。
故障轉移群集的筆記
引入 負載均衡等技術來解決 2 業務非常重要，屬於關鍵業務 通常和生產緊密聯絡 如 核電站的溫控系統 鋼鐵廠的製造管理系統 ica 交易 電子銀行 引入高可用技術，如 故障轉移群集 負載均衡 每乙個節點都可以對外提供服務 節點出現故障時，該節點的服務物件需要重新請求服務 故障轉移群集 任意時刻，只有...
SQLServer故障轉移群集的建立
本文主要給大家介紹如何建立sql server 故障轉移群集。在建立sql server 2000 故障轉移群集之前，必須配置 microsoft 群集服務 mscs 並使用 microsoft windows nt4.0 或 windows 2000 中的群集管理員建立至少乙個群集磁碟資源。在執行...
Heartbeat實現LVS的故障轉移
lvs是1998年5月由章文嵩博士發起和領導的優秀的集群解決方案，許多商業的集群產品，比如redhat的piranha，turbolinux公司的turbo cluster等，都是基於lvs的核心 的。在現實的應用中，lvs得到了大量的部署。1.3 用heartbeat實現lvs的高可用性 lvs可...