@[email protected]

上一篇介紹了負載均衡的內容和分類，這篇文章主要說明一下一些常用的負載均衡演算法。

   在實際的應用過程中，往往不會在不管伺服器是否滿載或者宕機讓客戶端的請求平均的被分配給內部的各個伺服器來處理。一般會讓配置更高的機器接受更多的服務請求，一臺處理服務請求較少的伺服器能分配到更多的服務請求，出現故障的伺服器將不再接受服務請求直至故障恢復等等。
   之所以要採用負載均衡的演算法或者策略，就是為了讓多個裝置在一起共同更好的完成任務，避免或則消除網路負載分佈不均、資料流量擁擠反應時間過長的瓶頸。

負載演算法

  解決後端系統的承載能力，，一般經常使用的有兩種方法，
  1）手動配置
  對於中小系統而言，手動配置是最方便有效的也是最穩定的方式。因為管理人員知道自己後端伺服器的引數配置，部署的服務，瞭解其大概的效能和承載能力，所以在配置的時候，可以預先分配好最大承載壓力。
  比如，某nginx的配置如下：
    upstream simplemain.com {
    server  192.168.1.100:8080 weight=30;
    server  192.168.1.101:8080 weight=70;
    }

   上述的配置的含義即有兩臺後端的伺服器，一臺的效能明顯優於另外一臺，更強的，我們就給他70%的壓力；弱一點的，我們就給他30%的壓力。這樣，nginx就會把更多的壓力分配給第二臺。

   這種方式配置簡單，而且很穩定，基本不會產生分配的抖動。不過，帶來的問題就是分配很固定，不能動態調整。如果你的後端伺服器有一段時間出現效能抖動（比如有其他服務擾動了機器的穩定執行，造成cpu利用率一段時間升高），前端呼叫者就很難根據實際的情況重新分配請求壓力。所以，引入了第二種方法。

2）動態調整
   該方案能夠根據機器目前的執行狀態，通過對比歷史平均值，如果發現當前狀態好過歷史平均值，就會增加請求壓力；如果發現比歷史平均狀況要糟糕，就會動態的請求減少請求的數量。

   這種方案的好處在於可以動態的來平衡後面伺服器的處理能力。不過，任何事物都有兩面性。這種方案如果遇到極端情況，可能會造成系統雪崩！當某臺機器出現短暫網路抖動的時候，他的響應就可能變慢，這個時候，前端服務就會將他的請求分配給其他的機器。如果分配的很多，就有可能造成某些機器響應也變慢。然後又將這些機器的請求分配給另外的……如此這般，執行著的機器終將被這些請求壓死。

   更好的方式是將兩者結合起來使用。通過預先靜態配置一個承載負荷的範圍，超過這個負荷就將其拋棄。同時動態的監控後端機器的響應情況，做出相應的動態請求調整。
 

均衡演算法

均衡演算法主要解決的問題是用何種方式將請求傳送給後端伺服器。

1)隨機（random）演算法
   依舊採用上面30-70的例子，演算法的虛擬碼描述：
   bool res = abs(rand()) % 100 < 30

1、先產生一個偽隨機數：rand()
2、將這個偽隨機數的轉化為非負數: abs(rand())
3、將這個數取模100，將值轉化到[0,100)的半開半閉區間：abs(rand()) % 100
4、看這個數是否落入了前30個數的區間[0,30)：abs(rand()) % 100 < 30
如果隨機是均勻的話，他們落到[0,100)這個區間裡一定是均勻的，所以只要在[0,30)這個區間裡，就分給第一臺機器，否則就分給第二臺機器。

   隨機演算法是最常用的演算法。從概率上講，它能保證請求基本是分散的，從而達到我們想要的均衡效果；其次，它又是無狀態的，不需要維持上一次的選擇狀態，也不需要均衡因子等。

2)輪訓（round-robin）演算法
   就像字面上的理解，輪訓演算法就像是挨個數數一樣（123-123-123……）。
   上面的例子的可表述為：

第一臺機器叫做A，第二臺叫做B：
1、先給兩臺機器做個排序的陣列：array = [ABBABBABBB]
2、用一個計數指標來標明現在陣列的位置：idx = 3
3、當一個請求來的時候，我們就把指標對應的機器選取出來，並且指標加一，挪到下一個位置。
這樣，十個請求，我們就可以保證有3個一定是A，7個一定是B。
因為要維護idx指標，所以輪詢演算法是有狀態的。

3)一致雜湊（consistent-hash）演算法
一致Hash要解決的是兩個問題：
   1、雜湊的不變性：就是同一個請求（比如：同一個使用者id）儘量的落入到一臺機器，不要因為時間等其他原因，落入到不同的機器上了；
   2、異常以後的分散性：當某些機器壞掉（或者增加機器），原來落到同一臺機器的請求（比如：使用者id為1，101，201），儘量分散到其他機器，不要都落入其他某一臺機器。這樣對於系統的衝擊和影響最小。

  一致Hash演算法用的最多的場景，就是分配cache服務。將某一個使用者的資料快取在固定的某臺伺服器上，那麼我們基本上就不用多臺機器都快取同樣的資料，這樣對我們提高快取利用率有極大的幫助。

  不過硬幣都是有兩面的，一致Hash也不例外。當某臺機器出問題以後，這臺機器上的cache失效，原先壓倒這臺機器上的請求，就會壓到其他機器上。由於其他機器原先沒有這些請求的快取，就有可能直接將請求壓到資料庫上，造成資料庫瞬間壓力增大。如果壓力很大的話，有可能直接把資料庫壓垮。

  所以，在考慮用一致Hash演算法的時候，一定要估計一下如果有機器宕掉後，後端系統是否能承受對應的壓力。如果不能，則建議浪費一點記憶體利用率，使用隨機演算法。


4)主備（master-slave）演算法
  演算法核心的思想是將請求儘量的放到某個固定機器的服務上，而其他機器的服務則用來做備份，如果出現問題就切換到另外的某臺機器的服務上。