溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊(cè)×
其他方式登錄
點(diǎn)擊 登錄注冊(cè) 即表示同意《億速云用戶服務(wù)條款》
  • 首頁 > 
  • 教程 > 
  • 服務(wù)器 > 
  • 掌握輕量級(jí)開源 Web云服務(wù)器Tengine負(fù)載均衡算法的方法和步驟

掌握輕量級(jí)開源 Web云服務(wù)器Tengine負(fù)載均衡算法的方法和步驟

發(fā)布時(shí)間:2020-04-20 11:28:00 來源:億速云 閱讀:269 作者:三月 欄目:服務(wù)器

下文給大家?guī)碚莆蛰p量級(jí)開源 Web云服務(wù)器Tengine負(fù)載均衡算法的方法和步驟,希望能夠給大家在實(shí)際運(yùn)用中帶來一定的幫助,負(fù)載均衡涉及的東西比較多,理論也不多,網(wǎng)上有很多書籍,今天我們就用億速云在行業(yè)內(nèi)累計(jì)的經(jīng)驗(yàn)做一個(gè)解答。以阿里巴巴為例。                                                           

在阿里七層流量入口接入層(Application Gateway)場(chǎng)景下, Nginx 官方的Smooth Weighted Round-Robin( SWRR )負(fù)載均衡算法已經(jīng)無法再完美施展它的技能。 Tengine 通過實(shí)現(xiàn)新的負(fù)載均衡算法Virtual Node Smooth Weighted Round-Robin(VNSWRR )不僅優(yōu)雅的解決了 SWRR 算法的缺陷,而且QPS處理能力相對(duì)于 Nginx 官方的 SWRR 算法提升了60%左右。

掌握輕量級(jí)開源 Web云服務(wù)器Tengine負(fù)載均衡算法的方法和步驟問題
接入層 Tengine 通過自研的動(dòng)態(tài) upstream 模塊實(shí)現(xiàn)動(dòng)態(tài)服務(wù)發(fā)現(xiàn),即運(yùn)行時(shí)動(dòng)態(tài)感知后端應(yīng)用機(jī)器擴(kuò)縮容、權(quán)重調(diào)整和健康檢查等信息。同時(shí)該功能可以做很多事情,比如用戶可通過調(diào)整后端應(yīng)用某臺(tái)機(jī)器的權(quán)重從而達(dá)到線上真實(shí)引流壓測(cè)目的。然而,這些操作在 Nginx 原生 SWRR 算法下卻可能引起不可逆轉(zhuǎn)的血案。
在接入層(Application Gateway)場(chǎng)景下, Nginx 的負(fù)載均衡算法 SWRR 會(huì)導(dǎo)致權(quán)重被調(diào)高機(jī)器的QPS瞬間暴漲,如上圖App2-host-A機(jī)器當(dāng)權(quán)重調(diào)整為2時(shí),某一時(shí)刻流量會(huì)集中轉(zhuǎn)發(fā)到該機(jī)器;
Nginx 的 SWRR 算法的處理時(shí)間復(fù)雜度是O(N),在大規(guī)模后端場(chǎng)景下 Nginx 的處理能力將線性下降;
綜上所述,對(duì)接入層 Tengine 的負(fù)載均衡轉(zhuǎn)發(fā)策略的改造及性能優(yōu)化已迫在眉睫。
原生 SWRR 算法分析
在介紹案列之前,我們先簡(jiǎn)單介紹下 Nginx 的負(fù)載均衡算法 SWRR 轉(zhuǎn)發(fā)策略及特點(diǎn):
SWRR 算法全稱是Smooth Weighted Round-Robin Balancing,顧名思義該算法相比于其它加權(quán)輪詢(WRR)算法多一個(gè)smooth(平滑)的特性。
下面我們就一個(gè)簡(jiǎn)單的列子來描述下該算法:
假設(shè)有3臺(tái)機(jī)器A、B、C權(quán)重分別為5、1、1,其中數(shù)組s代表機(jī)器列表、n代表機(jī)器數(shù)量,每個(gè)機(jī)器的cw初始化為0、ew初始化為機(jī)器權(quán)重、tw代表本輪選擇中所有機(jī)器的ew之和、best表示本輪被選中的機(jī)器。簡(jiǎn)單的描述就是每次選擇機(jī)器列表中cw值最大的機(jī)器,被選中機(jī)器的cw將會(huì)減去tw,從而降低下次被選中的機(jī)會(huì),簡(jiǎn)單的偽代碼描述如下:
best = NULL;
tw = 0;
for(i = random() % n; i != i || falg; i = (i + 1) % n) {
flag = 0;
s[i].cw += s[i].ew;
tw += s[i].ew;
if (best == NULL || s[i].cw > best->cw) {
best = &s[i];
}
}
best->cw -= tw;
return best;
請(qǐng)求編號(hào) 選擇前的權(quán)重值 被選中的server 選擇后的權(quán)重值

掌握輕量級(jí)開源 Web云服務(wù)器Tengine負(fù)載均衡算法的方法和步驟0 {5,1,1} A {-2,1,1}
1 {3,2,2} A {-4,2,2}
2 {1,3,3} B {1,-4,3}
3 {6,-3,4} A {-1,-3,4}
4 {4,-2,5} C {4,-2,-2}
5 {9,-1,-1} A {2,-1,-1}
6 {7,0,0} A {0,0,0}
其 SWRR 算法選擇的順序?yàn)椋簕 A, A, B, A, C, A, A }
而普通WRR算法選擇的順序可能為:{ C, B, A, A, A, A, A }
SWRR 相比于普通的WRR算法特點(diǎn):平滑、分散 。
調(diào)高權(quán)重引發(fā)的血案
從上面的描述來看, SWRR 算法似乎已經(jīng)比較完美了,但是在某些場(chǎng)景下還是有一定的缺陷,下面我們就一個(gè)真實(shí)的案列來看看它都有哪些缺陷:
一天早上,流量調(diào)度的同學(xué)匆忙的跑到我的工位,當(dāng)時(shí)看他神色是尤為的緊張,心想肯定是出啥問題了。果不其然:"為啥我把中心機(jī)房某臺(tái)機(jī)器的權(quán)重從1調(diào)整為2的時(shí)候,接入層 Tengine 并不是按照這個(gè)權(quán)重比例轉(zhuǎn)發(fā)流量恩?",當(dāng)時(shí)被調(diào)高機(jī)器QPS變化趨勢(shì)如下圖所示:
注:其中深藍(lán)色曲線表示權(quán)重被調(diào)高機(jī)器的QPS變化,淺綠色曲線表示該集群?jiǎn)螜C(jī)的平均QPS。
當(dāng)時(shí)看到這個(gè)流量趨勢(shì)變化圖的時(shí)候也是一臉茫然,不過好在有圖有數(shù)據(jù),那就可以先分析一下這個(gè)圖的幾個(gè)特征數(shù)字;由于部分?jǐn)?shù)據(jù)敏感,詳細(xì)數(shù)據(jù)分析就不在此處展開。直接描述其現(xiàn)象和原因:
被調(diào)高權(quán)重的機(jī)器當(dāng)時(shí)被分發(fā)到的流量基本上是該應(yīng)用機(jī)房總流量的1/2,一段時(shí)間后該機(jī)器的流量才恢復(fù)到預(yù)期的權(quán)重比例。其原因就是由于接入層 Tengine 對(duì)后端機(jī)器信息的變化是動(dòng)態(tài)感知熱生效的,而 Nginx 官方的 SWRR 算法策略第一次會(huì)選擇當(dāng)前機(jī)器列表中權(quán)重最大的機(jī)器轉(zhuǎn)發(fā)流量。從而進(jìn)一步導(dǎo)致已感知到后端機(jī)器權(quán)重變化的接入層 Tengine 都會(huì)將第一個(gè)請(qǐng)求轉(zhuǎn)發(fā)到權(quán)重被調(diào)高的機(jī)器上。
大規(guī)模下性能驟降
如下是在upstream里面配置2000個(gè)后端,在反向代理場(chǎng)景下壓測(cè) Nginx 的函數(shù)熱點(diǎn)圖如下所示。其中ngx_http_upstream_get_peer函數(shù)CPU消耗占比高達(dá)39%,其原因是因?yàn)?SWRR 算法的選取機(jī)器的時(shí)間復(fù)雜度為O(N) (其中N代表后端機(jī)器數(shù)量),這就相當(dāng)于每個(gè)請(qǐng)求都要執(zhí)行接近2000次循環(huán)才能找到對(duì)應(yīng)本次轉(zhuǎn)發(fā)的后端機(jī)器。
? 壓測(cè)環(huán)境
CPU型號(hào): Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
壓測(cè)工具:./wrk -t25 -d5m -c500 http://ip/t2000
Tengine 核心配置:配置2個(gè)worker進(jìn)程,壓力源 --長(zhǎng)連接--> Tengine / Nginx --短連接--> 后端
下面我們做個(gè)試驗(yàn),控制變量是 upstream 里面配置的 server 數(shù)量,觀察不同場(chǎng)景下 Nginx 的 QPS 處理能力以及響應(yīng)時(shí)間RT變化情況。從圖中可以發(fā)現(xiàn)當(dāng)后端 upstream 里面的 server 數(shù)量每增加500臺(tái)則 Nginx 的 QPS 處理能力下降 10% 左右,響應(yīng)RT增長(zhǎng) 1ms 左右。
從上面的分析基本上已經(jīng)確認(rèn)是 SWRR 算法存在如上兩個(gè)缺陷,下面就開始解決;
改進(jìn)的 VNSWRR 算法
雖然經(jīng)典的WRR算法(如隨機(jī)數(shù)方式實(shí)現(xiàn))可以在時(shí)間復(fù)雜度上達(dá)到 O(1) ,而且也可以避免 SWRR 算法調(diào)高權(quán)重的選取缺陷。但是在某些場(chǎng)景下(如小流量)可能造成后端的流量不均等問題,尤其是在流量瞬間暴漲的場(chǎng)景下有太多不可確定性。于是就構(gòu)思是否有一種算法即能擁有 SWRR 算法的平滑、分散特點(diǎn),又能具備 O(1) 的時(shí)間復(fù)雜度。所以就有了Virtual Node Smooth Weighted Round-Robin( VNSWRR )算法。
此處拿個(gè)列子來說明此算法:3臺(tái)機(jī)器A、B、C權(quán)重分別為1、2、3,N代表后端機(jī)器數(shù) 、TW代表后端機(jī)器權(quán)重總和。
算法關(guān)鍵點(diǎn)
o 虛擬節(jié)點(diǎn)初始化順序嚴(yán)格按照 SWRR 算法選取,保證初始化列表里的機(jī)器能夠分布足夠散列;
o 虛擬節(jié)點(diǎn)運(yùn)行時(shí)分批初始化,避免密集型計(jì)算集中。每批次虛擬節(jié)點(diǎn)使用完后再進(jìn)行下一批次虛擬節(jié)點(diǎn)列表初始化,每次只初始化min(n, max)個(gè)虛擬節(jié)點(diǎn);
算法描述
o Tengine 程序啟動(dòng)或者運(yùn)行時(shí)感知后端機(jī)器信息變化時(shí),則構(gòu)建TW個(gè)虛擬節(jié)點(diǎn)且第一次只初始化N個(gè)節(jié)點(diǎn)(注:TW代表后端機(jī)器權(quán)重之和,N代表后端機(jī)器數(shù));
o 各個(gè)進(jìn)程設(shè)置隨機(jī)起點(diǎn)輪詢位置,如上圖的Step 1對(duì)應(yīng)的列表其起

看了以上關(guān)于掌握輕量級(jí)開源 Web云服務(wù)器Tengine負(fù)載均衡算法的方法和步驟,如果大家還有什么地方需要了解的可以在億速云行業(yè)資訊里查找自己感興趣的或者找我們的專業(yè)技術(shù)工程師解答的,億速云技術(shù)工程師在行業(yè)內(nèi)擁有十幾年的經(jīng)驗(yàn)了。

 


向AI問一下細(xì)節(jié)

免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。

AI