分散式系統關注點：僅需這一篇，吃透 “負載均衡” 妥妥的

負載均衡分散式系統 · 發表 2018-10-05 17:20:28

摘要：本文長度為3426字，預計讀完需1.2MB流量，建議閱讀9分鐘。不知道大家國慶去哪玩了呢？感受如何。小Z我怕看到山海，愣是一點遊玩的慾望都沒有。而且看到下面這條訊息後，略有竊喜，哈哈。經中國旅遊研究院（文化和旅遊部資料中心）測算，10...

本文長度為 3426字 ，預計讀完需 1.2MB 流量，建議閱讀 9 分鐘。

不知道大家國慶去哪玩了呢？感受如何。小Z我怕看到山海，愣是一點遊玩的慾望都沒有。而且看到下面這條訊息後，略有竊喜，哈哈。

經中國旅遊研究院（文化和旅遊部資料中心）測算，10月1日-4日全國接待國內遊客5.02億人次，同比增長8.80%。

這兩天天氣開始轉涼了，記得添衣，特別是晚上出動的夜貓子們~

沒出門的小Z自然不能閒著，推送按時送達，大家在假期裡也不能忘記充電喲~

言歸正傳，上一篇《 ofollow,noindex">分散式系統關注點——初識「高可用」》我們對「 高可用 」有了一個初步認識，其中認為「 負載均衡 」是「高可用」的核心工作。那麼，本篇將通過圖文並茂的方式，來描述出每一種負載均衡策略的完整樣貌。

一、「負載均衡」是什麼

正如題圖所示的這樣，由一個獨立的統一入口來收斂流量，再做二次分發的過程就是「負載均衡」，它的本質和「 分散式系統 」一樣，是「分治」。

如果大家習慣了開車的時候用一些導航軟體，我們會發現，導航軟體的推薦路線方案會有一個數量的上限，比如3條、5條。因此，其實本質上它也起到了一個類似「負載均衡」的作用，因為如果只能取Top3的通暢路線，自然擁堵嚴重的路線就無法推薦給你了，使得車流的壓力被分攤到了相對空閒的路線上。

在軟體系統中也是一樣的道理，為了避免流量分攤不均，造成區域性節點負載過大（如CPU吃緊等），所以引入一個獨立的統一入口來做類似上面的“導航”的工作。但是，軟體系統中的「負載均衡」與導航的不同在於，導航是一個柔性策略，最終還是需要使用者做選擇，而前者則不同。

怎麼均衡的背後是策略在起作用，而策略的背後是由某些演算法或者說邏輯來組成的。比如，導航中的演算法屬於「路徑規劃」範疇，在這個範疇內又細分為「靜態路徑規劃」和「動態路徑規劃」，並且，在不同的分支下還有各種具體計算的演算法實現，如 Dijikstra、 A*等。同樣的，在軟體系統中的負載均衡，也有很多演算法或者說邏輯在支撐著這些策略，巧的是也有靜態和動態之分。

二、常用「負載均衡」策略圖解

下面來羅列一下日常工作中最常見的5種策略。

輪詢

這是最常用也最簡單策略，平均分配，人人都有、一人一次。大致的程式碼如下。

int  globalIndex = 0;   //注意是全域性變數，不是區域性變數。
try
{
    return servers[globalIndex];
}
finally
{
    globalIndex++;
    if (globalIndex == 3)
        globalIndex = 0;
}

加權輪詢

在輪詢的基礎上，增加了一個權重的概念。權重是一個泛化後的概念，可以用任意方式來體現，本質上是一個能者多勞思想。比如，可以根據宿主的效能差異配置不同的權重。大致的程式碼如下。

int matchedIndex = -1;
int total = 0;
for (int i = 0; i < servers.Length; i++)
{
      servers[i].cur_weight += servers[i].weight;//①每次迴圈的時候做自增（步長=權重值）
      total += servers[i].weight;//②將每個節點的權重值累加到彙總值中
      if (matchedIndex == -1 || servers[matchedIndex].cur_weight < servers[i].cur_weight) //③如果 當前節點的自增數 > 當前待返回節點的自增數，則覆蓋。
      {
            matchedIndex = i;
      }
}
 
servers[matchedIndex].cur_weight -= total;//④被選取的節點減去②的彙總值，以降低下一次被選舉時的初始權重值。
return servers[matchedIndex];

這段程式碼的過程如下圖的表格。"()"中的數字就是自增數，程式碼中的cur_weight。

值得注意的是，加權輪詢本身還有不同的實現方式，雖說最終的比例都是2：1：2。但是在請求送達的先後順序上可以所有不同。比如「5-4，3，2-1」和上面的案例相比，最終比例是一樣的，但是效果不同。「5-4，3，2-1」更容易產生併發問題，導致服務端擁塞，且這個問題隨著權重數字越大越嚴重。例子：10：5：3的結果是「18-17-16-15-14-13-12-11-10-9，8-7-6-5-4，3-2-1」

最少連線數

這是一種根據實時的負載情況，進行動態負載均衡的方式。 維護好活動中的連線數量，然後取最小的返回即可 。大致的程式碼如下。

var matchedServer = servers.orderBy(e => e.active_conns).first();
matchedServer.active_conns += 1;
return matchedServer;
//在連線關閉時還需對active_conns做減1的動作。

最快響應

這也是一種動態負載均衡策略，它的本質是根據每個節點對過去一段時間內的響應情況來分配，響應越快分配的越多。具體的運作方式也有很多，上圖的這種可以理解為，將最近一段時間的請求耗時的平均值記錄下來，結合前面的「加權輪詢」來處理，所以等價於2：1：3的加權輪詢。

題外話：一般來說，同機房下的延遲基本沒什麼差異，響應時間的差異主要在服務的處理能力上。如果在跨地域（例：浙江->上海，還是浙江->北京）的一些請求處理中運用，大多數情況會使用定時「ping」的方式來獲取延遲情況，因為是OSI的L3轉發，資料更乾淨，準確性更高。

Hash法

hash法的負載均衡與之前的幾種不同在於，它的結果是由客戶端決定的。通過客戶端帶來的某個標識經過一個標準化的雜湊函式進行打散分攤。

上圖中的雜湊函式運用的是最簡單粗暴的「取餘法」。

題外話：雜湊函式除了取餘之外，還有諸如「變基」、「摺疊」、「平方取中法」等等，此處不做展開，有興趣的小夥伴可自行查閱資料。

另外，被求餘的引數其實可以是任意的，只要最終轉化成一個整數參與運算即可。最常用的應該是用來源ip地址作為引數，這樣可以確保相同的客戶端請求儘可能落在同一臺伺服器上。

三、常用「 負載均衡 」策略優缺點和適用場景

我們知道，沒有完美的事物，負載均衡策略也是一樣。上面列舉的這些最常用的策略也有各自的優缺點和適用場景，我稍作了整理，如下。

這些負載均衡演算法之所以常用也是因為簡單，想要更優的效果，必然就需要更高的複雜度。比如，可以將簡單的策略組合使用、或者通過更多維度的資料取樣來綜合評估、甚至是基於進行資料探勘後的預測演算法來做。

四、用「 健康探測 」來保障高可用

不管是什麼樣的策略，難免會遇到機器故障或者程式故障的情況。所以要確保負載均衡能更好的起到效果，還需要結合一些「健康探測」機制。定時的去探測服務端是不是還能連上，響應是不是超出預期的慢。如果節點屬於“不可用”的狀態的話，需要將這個節點臨時從待選取列表中移除，以提高可用性。一般常用的「健康探測」方式有3種。

HTTP探測

使用Get/Post的方式請求服務端的某個固定的URL，判斷返回的內容是否符合預期。一般使用Http狀態碼、response中的內容來判斷。

TCP探測

基於Tcp的三次握手機制來探測指定的IP + 埠。最佳實踐可以借鑑阿里雲的SLB機制，如下圖。