公司去年上了F5,好用是好用，但是費用太高昂了，所以最近一直在研究軟負載均衡這一塊兒，恰巧今年年初谷歌開源了seesaw，讓自己可以繞過很多彎路。特此總結下之前瞭解的負載均衡策略。 －Sunface

在分散式系統中，負載均衡是非常重要的環節，通過負載均衡將請求派發到網路中的一個或多個節點上進行處理。通常來說，負載均衡分為硬體負載均衡及軟體負載均衡。硬體負載均衡，顧名思義，在伺服器節點之間安裝專門的硬體進行負載均衡的工作，F5便為其中的佼佼者。軟體負載均衡則是通過在伺服器上安裝的特定的負載均衡軟體或是自帶負載均衡模組完成對請求的分配派發。

一般而言，有以下幾種常見的負載均衡策略：

一.輪詢。作為非常經典的負載均衡策略，早期該策略應用地非常廣泛。其原理很簡單，給每個請求標記一個序號，然後將請求依次派發到伺服器節點中，適用於叢集中各個節點提供服務能力等同且無狀態的場景。其缺點也非常明顯，該策略將節點視為等同，與實際中複雜的環境不符。加權輪詢為輪詢的一個改進策略，每個節點會有權重屬性，但是因為權重的設定難以做到隨實際情況變化，仍有一定的不足。

二.隨機。與輪詢相似，只是不需要對每個請求進行編號，每次隨機取一個。同樣地，該策略也將後端的每個節點是為等同的。另外同樣也有改進的加權隨機的演算法，不再贅述。

三.最小響應時間。通過記錄每次請求所需的時間，得出平均的響應時間，然後根據響應時間選擇最小的響應時間。該策略能較好地反應伺服器的狀態，但是由於是平均響應時間的關係，時間上有些滯後，無法滿足快速響應的要求。因此在此基礎之上，會有一些改進版本的策略，如只計算最近若干次的平均時間的策略等。

四. 最小併發數。客戶端的每一次請求服務在伺服器停留的時間可能會有較大的差異,隨著工作時間加長,如果採用簡單的輪循或隨機均衡演算法,每一臺伺服器上的連線程序可能會產生較大的不同,並沒有達到真正的負載均衡｡最小併發數的策略則是記錄了當前時刻，每個備選節點正在處理的事務數，然後選擇併發數最小的節點。該策略能夠快速地反應伺服器的當前狀況，較為合理地將負責分配均勻，適用於對當前系統負載較為敏感的場景。

五.雜湊。在後端節點有狀態的情況下，需要使用雜湊的方法進行負載均衡，此種情況下情況比較複雜，本文對此不做探討。

另外還有其他的負載均衡策略不再一一列舉，有興趣的同學可以自己去查閱相關資料。

分散式系統面臨著遠比單機系統更加複雜的環境，包括不同的網路環境、執行平臺、機器配置等等。在如此複雜的環境中，發生錯誤是不可避免的，然後如何能夠做到容錯性，將發生錯誤的代價降低到最低是在分散式系統中必須要考慮的問題。選擇不同的負載均衡策略將會有非常大的不同。

考慮下列的情況。完成請求需要如下四個叢集，A,B,C,D，其中，假定完成呼叫需要呼叫叢集B3次，B叢集共有5臺伺服器。

當叢集B中的某臺伺服器出現故障而導致無法提供服務，若叢集中其他容錯手段尚未生效，那麼理想情況下，4/5的請求不受影響。

若採用輪詢或隨機的負載均衡策略時，單次請求派發到正常節點的概率為4/5,那麼該請求成功的機率為1  (4/5) (4/5)*(4/5) = 64/125  約為 二之一，低於4/5的理想狀態。 

在因此，在此種情況下，若僅僅採用此種策略，會使故障的影響範圍擴散，不符合預期。

若採用最小併發數的複雜均衡策略，假定正常一個請求需耗時10ms，超時時間設定為1s，那麼，按照最小併發數的策略，異常節點的提供服務的能力為1，正常節點提供服務能力為100，則派發到異常節點的概率為1/(100  4+1)=1/401,該請求成功的機率為1(400/401)^3≈99.25%，高於4/5。 

更加一般地，設叢集中發生故障的故障機器的比例p，那麼呼叫成功的預期概率為

整個請求需要呼叫k次，若採用輪詢或隨機的負載均衡策略，那麼單次派發到正常節點的概率為

請求的成功率便會下降到

當k為3的時候，得到成功率f(p)與p的關係：

從上圖可知，在p在增大的時候，請求的成功率f(p)便會有明顯的下降，故而在對可靠性要求比較高的分散式系統中，不能簡單地採用此種策略。                 若採用最小併發數的策略，叢集伺服器的總數為m，假定異常情況下服務能力下降到正常的1/q，那麼單位時間內，叢集能提供服務的總數為

那麼單次派發到正常節點的概率為:

請求的成功率則是上述值的k次方，即

當q=10，k=3時，可以得到請求成功率f(p)的影象:

從上圖可知，當p在較小的區間內變化時(如(0,0.4])，隨著p的增大,成功率f(p)並未有明顯的下降，在每個節點可以承受服務壓力的情況下，可以良好地處理多個節點故障的異常狀況。

換個角度思考，再挖掘一下上述等式，若p為恆定，即叢集中若已有一定數量的機器發生了故障。

當p=0.1,k=3時，可以得到成功率f(q)的影象:

從上圖可知，服務的超時時間無須設定地過大，一般來說，設定為10倍的正常提供伺服器時間即可。

另外，若是在異常情況非常快地被客戶端感知到並反饋的時候(如客戶端檢查到後端某個節點配置錯誤等)，即q<1的時候，假定q=0.1,k=3的時候，可以得到如下關係：

在此種情況下，會導致失敗大大提升，即使只有較小比例的叢集出現異常，也會使得請求大量失敗，故而還需要其他手段檢測到此型別的異常。

針對這種情況，再考慮到網路波動及其他異常的狀態，添加了移除異常節點的保護機制，當後端的某一個節點連續失敗超過一定次數時，則就會移除該節點。但是該種策略亦存在因為使用者輸入錯誤或其他偶然因素導致返回失敗而使得正常節點被移除的情況。考慮一下這種情況，假定這種返回異常的概率為1%，移除節點的失敗次數的閥值為9，q=0.1，可用節點數為5，根據上述最小併發數的計算公式，可以得到派發到這一節點的概率為2/7，那麼連續派發到該節點的概率為(2/7)^9≈0.001%，可以忽略掉這種異常情況。

在實際應用中，客戶端的併發數可能存在一直維持在一個較低的水平上，由於客戶端的併發數並不能代表服務端的併發情況，會造成在客戶端併發數較小的情況下，服務端實際負載不均衡的狀況。

故而，最小併發數的負載均衡策略不適用於在客戶端做負載均衡，且客戶端負載較小的情況。這種情況下，目前採用隨機的方法解決負載不均衡的問題。            當然，在實際的分散式系統中，因為一個節點異常而導致其他節點的壓力增大，可能會使其他節點的效能下降，他們之間的關係難以用上述的等式簡單地描述