背景

一般生產(chǎn)環(huán)境單機(jī)所能承受的QPS壓力為2w左右，過大的壓力會(huì)導(dǎo)致服務(wù)器爆炸。即便是單機(jī)能夠撐住2w QPS，一般也不會(huì)這么做，生產(chǎn)環(huán)境一般會(huì)預(yù)留50%的冗余能力，防止QPS因?yàn)槟硞€(gè)熱門的活動(dòng)而爆炸。當(dāng)QPS超過單機(jī)所能承受的壓力時(shí)，自然而然會(huì)想到引入分布式集群。那么，某一個(gè)請求會(huì)被哪臺(tái)服務(wù)器處理呢，這是隨機(jī)的，還是說按照一定的規(guī)則處理的？這就是負(fù)載均衡算法所要干的事。

負(fù)載均衡器

負(fù)載均衡器就是實(shí)現(xiàn)一種或者多種負(fù)載均衡算法的軟件或者硬件設(shè)備。負(fù)載均衡器根據(jù)協(xié)議層的不同，通常又分為兩種，第一種在四層傳輸層實(shí)現(xiàn)，第二種就是在七層應(yīng)用層實(shí)現(xiàn)。

很多專用的硬件負(fù)載均衡器都支持在TCP層實(shí)現(xiàn)負(fù)載均衡，效率高。當(dāng)然TCP層實(shí)現(xiàn)負(fù)載均衡有它的缺點(diǎn)，如無法保存長連接等。所以一般類似于BAT這種大公司，都是多層負(fù)載均衡配合的。

一般純軟件實(shí)現(xiàn)的通常在應(yīng)用層來實(shí)現(xiàn)，這也是應(yīng)用比較多的一種實(shí)現(xiàn)方式。目前比較流行的實(shí)現(xiàn)有Nginx、HAProxy、Keepalived等。當(dāng)然Linux內(nèi)核自帶的LVS(Linux Virtual Server)就是四層的實(shí)現(xiàn)。

輪詢(Round Robin)

輪詢是一種很簡單的實(shí)現(xiàn)，依次將請求分配給后端服務(wù)器。

• 優(yōu)點(diǎn)：實(shí)現(xiàn)簡單，請求均勻分配。
• 缺點(diǎn)：請求均勻分配，因?yàn)楹蠖朔?wù)器通常性能會(huì)有差異，所以希望性能好的服務(wù)器能夠多承擔(dān)一部分。也不適合對長連接和命中率有要求的場景。

加權(quán)輪詢(Weighted Round Robin)

加權(quán)本質(zhì)是一種帶優(yōu)先級(jí)的方式，加權(quán)輪詢就是一種改進(jìn)的輪詢算法，輪詢算法是權(quán)值相同的加權(quán)輪詢。需要給后端每個(gè)服務(wù)器設(shè)置不同的權(quán)值，決定分配的請求數(shù)比例。這個(gè)算法應(yīng)用就相當(dāng)廣泛了，對于無狀態(tài)的負(fù)載場景，非常適合。

• 優(yōu)點(diǎn)：解決了服務(wù)器性能不一的情況
• 缺點(diǎn)：權(quán)值需要靜態(tài)配置，無法自動(dòng)調(diào)節(jié)。也不適合對長連接和命中率有要求的場景。

隨機(jī)Random

隨機(jī)把請求分配給后端服務(wù)器。請求分配的均勻程度依賴于隨機(jī)算法了，因?yàn)閷?shí)現(xiàn)簡單，常常用于配合處理一些極端的情況，如出現(xiàn)熱點(diǎn)請求，這個(gè)時(shí)候就可以random到任意一臺(tái)后端，以分散熱點(diǎn)。當(dāng)然缺點(diǎn)也不言而喻。

哈希Hash

哈希算法想必大家并不陌生，應(yīng)用最為廣泛。根據(jù)Source IP、 Destination IP、URL、或者其它，算hash值或者md5，再采用取模。比如有N臺(tái)服務(wù)器: S1、S2、S3……Sn

hash值 % N

顯然，相同的請求會(huì)被映射到相同的后端。這非常適合維護(hù)長連接和提高命中率。
但是它天生也有一些缺點(diǎn)。比如說，現(xiàn)在某個(gè)請求通過哈希被映射到S3上去了，如果S3宕機(jī)了，就不得不二次Hash，重新計(jì)算路由時(shí)會(huì)剔除宕機(jī)的后端。

hash值 % (N - 1)

這樣會(huì)導(dǎo)致幾乎所有請求路由產(chǎn)生變化。由此導(dǎo)致命中率的急劇下降。當(dāng)然一般生產(chǎn)環(huán)境通過提供S3的備機(jī)來解決這種問題，但是主備之間切換也是需要時(shí)間，它們之間的數(shù)據(jù)同步也是有延時(shí)的。所以需要根據(jù)業(yè)務(wù)場景來權(quán)衡了。
擴(kuò)容也會(huì)有類似的問題，計(jì)算路由公式變?yōu)?#xff1a;

hash值 % (N + 1)　

為了解決這種問題，一般生產(chǎn)環(huán)境可能采用成倍擴(kuò)容的方式。N -> 2N，這樣求路由可以做到與原來保持一致。當(dāng)然必不可少的造成機(jī)器資源的浪費(fèi)。請各位看官自行權(quán)衡。
對于熱點(diǎn)請求，這種Hash算法也可能成在雪崩效應(yīng)，取決于采用何種Hash，基于URL還是基于IP等。總之，不能把熱點(diǎn)請求路由到單機(jī)上，否則單機(jī)撐不住，會(huì)逐個(gè)逐個(gè)被打爆，也就是雪崩效應(yīng)。

最小連接數(shù)LC

最小連接數(shù)(Least Connection)，把請求分配給活動(dòng)連接數(shù)最小的后端服務(wù)器。它通過活動(dòng)來估計(jì)服務(wù)器的負(fù)載。比較智能，但需要維護(hù)后端服務(wù)器的連接列表。

加權(quán)最小連接數(shù)WLC

加權(quán)最小連接數(shù)(Weighted Least Connection)，在后端服務(wù)器性能差異較大的情況下，可以優(yōu)化LC的性能，高權(quán)值的服務(wù)可以承受更多的連接負(fù)載。

最短響應(yīng)時(shí)間LRT

最短響應(yīng)時(shí)間(Least Response Time)，把請求分配給平均響應(yīng)時(shí)間最短的后端服務(wù)器。平均響應(yīng)時(shí)間可以通過ping探測請求或者正常請求響應(yīng)時(shí)間獲取。
RT(Response Time)是衡量服務(wù)器負(fù)載的一個(gè)非常重要的指標(biāo)。對于響應(yīng)很慢的服務(wù)器，說明其負(fù)載一般很高了，應(yīng)該降低它的QPS。

之前有人說使用CPU占用率作為負(fù)載均衡的指標(biāo)，只能說沒理解CPU占用率的實(shí)質(zhì)。理論上CPU占用率是越高越好，說明服務(wù)充分利用了CPU資源。但對于設(shè)計(jì)不合理的程序?qū)е碌腃PU占用過高這是程序的設(shè)計(jì)問題，并不違背這條理論。

?

常用「負(fù)載均衡」策略優(yōu)缺點(diǎn)和適用場景

?

參考文獻(xiàn)

• 深入一致性哈希(Consistent Hashing)算法原理，并附100行代碼實(shí)現(xiàn)

?

轉(zhuǎn)載于:https://www.cnblogs.com/kaleidoscope/p/9754489.html

總結(jié)

以上是生活随笔為你收集整理的常用负载均衡策略分析的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。