負載均衡的幾種常用方案

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

以輪詢的方式依次請求排程不同的伺服器；

實現時，一般為伺服器帶上權重；這樣有兩個好處：

針對伺服器的效能差異可分配不同的負載；

當需要將某個結點剔除時，只需要將其權重設定為0即可；

優點：實現簡單、高效；易水平擴充套件；

缺點：請求到目的結點的不確定，造成其無法適用於有寫的場景（快取，資料庫寫）

應用場景：資料庫或應用服務層中只有讀的場景；

請求隨機分布到各個結點；在資料足夠大的場景能達到乙個均衡分布；

優點：實現簡單、易水平擴充套件；

缺點：同round robin，無法用於有寫的場景；

應用場景：資料庫負載均衡，也是只有讀的場景；

根據key來計算需要落在的結點上，可以保證乙個同乙個鍵一定落在相同的伺服器上；

優點：相同key一定落在同乙個結點上，這樣就可用於有寫有讀的快取場景；

缺點：在某個結點故障後，會導致雜湊鍵重新分布，造成命中率大幅度下降；

解決：一致性雜湊 or 使用keepalived保證任何乙個結點的高可用性，故障後會有其它結點頂上來；

應用場景：快取，有讀有寫；

在伺服器乙個結點出現故障時，受影響的只有這個結點上的key，最大程度的保證命中率；

如twemproxy中的ketama方案；

生產實現中還可以規劃指定子key雜湊，從而保證區域性相似特徵的鍵能分布在同乙個伺服器上；

優點：結點故障後命中率下降有限；

應用場景：快取；

根據鍵的範圍來負載，前1億個鍵都存放到第乙個伺服器，1~2億在第二個結點；

優點：水平擴充套件容易，儲存不夠用時，加伺服器存放後續新增資料；

缺點：負載不均；資料庫的分布不均衡；（資料有冷熱區分，一般最近註冊的使用者更加活躍，這樣造成後續的伺服器非常繁忙，而前期的結點空閒很多）

適用場景：資料庫分片負載均衡；

根據鍵對伺服器結點數取模來負載；比如有4臺伺服器，key取模為0的落在第乙個結點，1落在第二個結點上。

優點：資料冷熱分布均衡，資料庫結點負載均衡分布；

缺點：水平擴充套件較難；

適用場景：資料庫分片負載均衡；

根據cpu、io、網路的處理能力來決策接下來的請求如何排程；

優點：充分利用伺服器的資源，保證個結點上負載處理均衡；

缺點：實現起來複雜，真實使用較少；

使用訊息佇列轉為非同步模型，將負載均衡的問題消滅

負載均衡是一種推模型，一直向你發資料，那麼，將所有的使用者請求發到訊息佇列中，所有的下游結點誰空閒，誰上來取資料處理；轉為拉模型之後，消除了對下行結點負載的問題；

優點：通過訊息佇列的緩衝，保護後端系統，請求劇增時不會沖垮後端伺服器；

水平擴充套件容易，加入新結點後，直接取queue即可；

缺點：不具有實時性；

應用場景：不需要實時返回的場景；

比如，12036下訂單後，立刻返回提示資訊：您的訂單進去排隊了...等處理完畢後，再非同步通知；

posted by: 大cc | 27nov,2015

部落格：blog.me115.com [訂閱]

github：大cc

負載均衡的幾種常用方案

總結下負載均衡的常用方案及適用場景 以輪詢的方式依次請求排程不同的伺服器 實現時，一般為伺服器帶上權重 這樣有兩個好處 針對伺服器的效能差異可分配不同的負載 當需要將某個結點剔除時，只需要將其權重設定為0即可 優點 實現簡單 高效 易水平擴充套件 缺點 請求到目的結點的不確定，造成其無法適用於有寫的...

負載均衡的幾種常用方式

理解負載均衡，必須先搞清楚正向 和反向 注 當一台伺服器的單位時間內的訪問量越大時，伺服器壓力就越大，大到超過自身承受能力時，伺服器就會崩潰。為了避免伺服器崩潰，讓使用者有更好的體驗，我們通過負載均衡的方式來分擔伺服器壓力。我們可以建立很多很多伺服器，組成乙個伺服器集群，當使用者訪問 時，先訪問乙個...

架構方案 22 幾種負載均衡分類

負載均衡其實就是任務的分發，使得任務能按照你的 預想分配到各個計算單元上，它能提高服務對外的效能，避免單點失效場景。這裡要注意的一點是雖說叫負載均衡，但是有時候我們的分配演算法就是不是均衡的。比如配個nginx，做兩台伺服器的負載均衡，一台機子比較老是以前的配置比較低，一台是新機子配置高，那我們的分...