負載均衡的幾種常用方案

2021-09-07 03:56:15 字數 1568 閱讀 3967

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

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

實現時,一般為伺服器帶上權重;這樣有兩個好處:

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

當需要將某個結點剔除時,只需要將其權重設定為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,做兩台伺服器的負載均衡,一台機子比較老是以前的配置比較低,一台是新機子配置高,那我們的分...