負載均衡的幾種常用方案

大CC發表於2015-11-27
負載

負載均衡的幾種常用方案

總結下負載均衡的常用方案及適用場景；

Round Robin 輪詢排程

以輪詢的方式依次請求排程不同的伺服器；
實現時，一般為伺服器帶上權重；這樣有兩個好處：

  1. 針對伺服器的效能差異可分配不同的負載；
  2. 當需要將某個結點剔除時，只需要將其權重設定為0即可；

優點：實現簡單、高效；易水平擴充套件；
缺點：請求到目的結點的不確定，造成其無法適用於有寫的場景（快取，資料庫寫）
應用場景：資料庫或應用服務層中只有讀的場景；

隨機方式

請求隨機分佈到各個結點；在資料足夠大的場景能達到一個均衡分佈；
優點：實現簡單、易水平擴充套件；
缺點：同Round Robin，無法用於有寫的場景；
應用場景：資料庫負載均衡，也是隻有讀的場景；

雜湊方式

根據key來計算需要落在的結點上，可以保證一個同一個鍵一定落在相同的伺服器上；
優點：相同key一定落在同一個結點上，這樣就可用於有寫有讀的快取場景；
缺點：在某個結點故障後，會導致雜湊鍵重新分佈，造成命中率大幅度下降；
解決：一致性雜湊 or 使用keepalived保證任何一個結點的高可用性，故障後會有其它結點頂上來；
應用場景：快取，有讀有寫；

一致性雜湊

在伺服器一個結點出現故障時，受影響的只有這個結點上的key，最大程度的保證命中率；
如twemproxy中的ketama方案；
生產實現中還可以規劃指定子key雜湊，從而保證區域性相似特徵的鍵能分佈在同一個伺服器上；
優點：結點故障後命中率下降有限；
應用場景：快取；

根據鍵的範圍來負載

根據鍵的範圍來負載，前1億個鍵都存放到第一個伺服器，1~2億在第二個結點；
優點：水平擴充套件容易，儲存不夠用時，加伺服器存放後續新增資料；
缺點：負載不均；資料庫的分佈不均衡；（資料有冷熱區分，一般最近註冊的使用者更加活躍，這樣造成後續的伺服器非常繁忙，而前期的結點空閒很多）
適用場景：資料庫分片負載均衡；

根據鍵對伺服器結點數取模來負載；

根據鍵對伺服器結點數取模來負載；比如有4臺伺服器，key取模為0的落在第一個結點，1落在第二個結點上。
優點：資料冷熱分佈均衡，資料庫結點負載均衡分佈；
缺點：水平擴充套件較難；
適用場景：資料庫分片負載均衡；

純動態結點負載均衡

根據CPU、IO、網路的處理能力來決策接下來的請求如何排程；
優點：充分利用伺服器的資源，保證個結點上負載處理均衡；
缺點：實現起來複雜，真實使用較少；

不用主動負載均衡；

使用訊息佇列轉為非同步模型，將負載均衡的問題消滅
負載均衡是一種推模型，一直向你發資料，那麼，將所有的使用者請求發到訊息佇列中，所有的下游結點誰空閒，誰上來取資料處理；轉為拉模型之後，消除了對下行結點負載的問題；
優點：通過訊息佇列的緩衝，保護後端系統，請求劇增時不會沖垮後端伺服器；
水平擴充套件容易，加入新結點後，直接取queue即可；
缺點：不具有實時性；
應用場景：不需要實時返回的場景；
比如，12036下訂單後，立刻返回提示資訊：您的訂單進去排隊了...等處理完畢後，再非同步通知；

相關開源工具

  • HAProxy：可用來做redis多個結點的負載均衡、也可做mysql等資料庫的負載、支援4層負載和7層負載；（一般配合Keepalived做高可用）

  • Twemproxy：用來做redis的結點的分片、redis的儲存受限與單個結點的記憶體容量，資料量大到需要分片，使用twemproxy可做到對業務層透明的分片；
    twemproxy也是使用的單執行緒reactor模型，一個twemproxy後端接再多的redis結點，其能夠支撐的TPS不會超過單個redis結點的處理能力，使用時需要啟動多個twemproxy對外提供查詢結點；

  • nginx：目前的明星開源產品，只支援7層負載，除了用於反向代理負載均衡，更出名的是作為WEB伺服器；

  • LVS：使用Linux核心叢集實現一個高效能、高可用的負載均衡伺服器，採用IP負載均衡技術和基於內容請求分發技術。未用過這個，有興趣的同學可看看這篇文章：http://www.ha97.com/5646.html；

Posted by: 大CC | 27NOV,2015
部落格：blog.me115.com [訂閱]
Github：大CC

相關文章