負載均衡的幾種常用方案

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

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