負載均衡的幾種經常使用方案

負載均衡的幾種經常使用方案

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

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