Web服務(wù)器Tengine負(fù)載均衡算法是什么

這篇文章主要介紹“Web服務(wù)器Tengine負(fù)載均衡算法是什么”，在日常操作中，相信很多人在Web服務(wù)器Tengine負(fù)載均衡算法是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Web服務(wù)器Tengine負(fù)載均衡算法是什么”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

問題

接入層 Tengine 通過自研的動態(tài) upstream 模塊實現(xiàn)動態(tài)服務(wù)發(fā)現(xiàn)，即運行時動態(tài)感知后端應(yīng)用機(jī)器擴(kuò)縮容、權(quán)重調(diào)整和健康檢查等信息。同時該功能可以做很多事情，比如用戶可通過調(diào)整后端應(yīng)用某臺機(jī)器的權(quán)重從而達(dá)到線上真實引流壓測目的。然而，這些操作在 Nginx 原生 SWRR 算法下卻可能引起不可逆轉(zhuǎn)的血案。

? 在接入層（Application Gateway）場景下， Nginx 的負(fù)載均衡算法 SWRR 會導(dǎo)致權(quán)重被調(diào)高機(jī)器的QPS瞬間暴漲，如上圖App2-host-A機(jī)器當(dāng)權(quán)重調(diào)整為2時，某一時刻流量會集中轉(zhuǎn)發(fā)到該機(jī)器；

? Nginx 的 SWRR 算法的處理時間復(fù)雜度是O(N)，在大規(guī)模后端場景下 Nginx 的處理能力將線性下降；

綜上所述，對接入層 Tengine 的負(fù)載均衡轉(zhuǎn)發(fā)策略的改造及性能優(yōu)化已迫在眉睫。

原生 SWRR 算法分析

在介紹案列之前，我們先簡單介紹下 Nginx 的負(fù)載均衡算法 SWRR 轉(zhuǎn)發(fā)策略及特點：

SWRR 算法全稱是Smooth Weighted Round-Robin Balancing，顧名思義該算法相比于其它加權(quán)輪詢（WRR）算法多一個smooth（平滑）的特性。

下面我們就一個簡單的列子來描述下該算法：

假設(shè)有3臺機(jī)器A、B、C權(quán)重分別為5、1、1，其中數(shù)組s代表機(jī)器列表、n代表機(jī)器數(shù)量，每個機(jī)器的cw初始化為0、ew初始化為機(jī)器權(quán)重、tw代表本輪選擇中所有機(jī)器的ew之和、best表示本輪被選中的機(jī)器。簡單的描述就是每次選擇機(jī)器列表中cw值最大的機(jī)器，被選中機(jī)器的cw將會減去tw，從而降低下次被選中的機(jī)會，簡單的偽代碼描述如下：

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;

請求編號 選擇前的權(quán)重值 被選中的server 選擇后的權(quán)重值
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 算法選擇的順序為：{ A, A, B, A, C, A, A }

而普通WRR算法選擇的順序可能為：{ C, B, A, A, A, A, A }

SWRR 相比于普通的WRR算法特點：平滑、分散 。

調(diào)高權(quán)重引發(fā)的血案

從上面的描述來看， SWRR 算法似乎已經(jīng)比較完美了，但是在某些場景下還是有一定的缺陷，下面我們就一個真實的案列來看看它都有哪些缺陷：

一天早上，流量調(diào)度的同學(xué)匆忙的跑到我的工位，當(dāng)時看他神色是尤為的緊張，心想肯定是出啥問題了。果不其然："為啥我把中心機(jī)房某臺機(jī)器的權(quán)重從1調(diào)整為2的時候，接入層 Tengine 并不是按照這個權(quán)重比例轉(zhuǎn)發(fā)流量恩？"，當(dāng)時被調(diào)高機(jī)器QPS變化趨勢如下圖所示：

注：其中深藍(lán)色曲線表示權(quán)重被調(diào)高機(jī)器的QPS變化，淺綠色曲線表示該集群單機(jī)的平均QPS。

當(dāng)時看到這個流量趨勢變化圖的時候也是一臉茫然，不過好在有圖有數(shù)據(jù)，那就可以先分析一下這個圖的幾個特征數(shù)字；由于部分?jǐn)?shù)據(jù)敏感，詳細(xì)數(shù)據(jù)分析就不在此處展開。直接描述其現(xiàn)象和原因：

被調(diào)高權(quán)重的機(jī)器當(dāng)時被分發(fā)到的流量基本上是該應(yīng)用機(jī)房總流量的1/2，一段時間后該機(jī)器的流量才恢復(fù)到預(yù)期的權(quán)重比例。其原因就是由于接入層 Tengine 對后端機(jī)器信息的變化是動態(tài)感知熱生效的，而 Nginx 官方的 SWRR 算法策略第一次會選擇當(dāng)前機(jī)器列表中權(quán)重最大的機(jī)器轉(zhuǎn)發(fā)流量。從而進(jìn)一步導(dǎo)致已感知到后端機(jī)器權(quán)重變化的接入層 Tengine 都會將第一個請求轉(zhuǎn)發(fā)到權(quán)重被調(diào)高的機(jī)器上。

大規(guī)模下性能驟降

如下是在upstream里面配置2000個后端，在反向代理場景下壓測 Nginx 的函數(shù)熱點圖如下所示。其中ngx_http_upstream_get_peer函數(shù)CPU消耗占比高達(dá)39%，其原因是因為 SWRR 算法的選取機(jī)器的時間復(fù)雜度為O(N) (其中N代表后端機(jī)器數(shù)量)，這就相當(dāng)于每個請求都要執(zhí)行接近2000次循環(huán)才能找到對應(yīng)本次轉(zhuǎn)發(fā)的后端機(jī)器。

? 壓測環(huán)境

CPU型號： Intel(R) Xeon(R) CPU E5-2682 v4 @ 2.50GHz
壓測工具：./wrk -t25 -d5m -c500 'http://ip/t2000'

Tengine 核心配置：配置2個worker進(jìn)程，壓力源 --長連接-->  Tengine / Nginx  --短連接--> 后端

下面我們做個試驗，控制變量是 upstream 里面配置的 server 數(shù)量，觀察不同場景下 Nginx 的 QPS 處理能力以及響應(yīng)時間RT變化情況。從圖中可以發(fā)現(xiàn)當(dāng)后端 upstream 里面的 server 數(shù)量每增加500臺則 Nginx 的 QPS 處理能力下降 10% 左右，響應(yīng)RT增長 1ms 左右。

從上面的分析基本上已經(jīng)確認(rèn)是 SWRR 算法存在如上兩個缺陷，下面就開始解決；

改進(jìn)的 VNSWRR 算法

雖然經(jīng)典的WRR算法（如隨機(jī)數(shù)方式實現(xiàn)）可以在時間復(fù)雜度上達(dá)到 O(1) ，而且也可以避免 SWRR 算法調(diào)高權(quán)重的選取缺陷。但是在某些場景下（如小流量）可能造成后端的流量不均等問題，尤其是在流量瞬間暴漲的場景下有太多不可確定性。于是就構(gòu)思是否有一種算法即能擁有 SWRR 算法的平滑、分散特點，又能具備 O(1) 的時間復(fù)雜度。所以就有了Virtual Node Smooth Weighted Round-Robin（ VNSWRR ）算法。

此處拿個列子來說明此算法：3臺機(jī)器A、B、C權(quán)重分別為1、2、3，N代表后端機(jī)器數(shù) 、TW代表后端機(jī)器權(quán)重總和。

算法關(guān)鍵點

o 虛擬節(jié)點初始化順序嚴(yán)格按照 SWRR 算法選取，保證初始化列表里的機(jī)器能夠分布足夠散列；
o 虛擬節(jié)點運行時分批初始化，避免密集型計算集中。每批次虛擬節(jié)點使用完后再進(jìn)行下一批次虛擬節(jié)點列表初始化，每次只初始化min(n, max)個虛擬節(jié)點；

算法描述

o Tengine 程序啟動或者運行時感知后端機(jī)器信息變化時，則構(gòu)建TW個虛擬節(jié)點且第一次只初始化N個節(jié)點（注：TW代表后端機(jī)器權(quán)重之和，N代表后端機(jī)器數(shù)）；
o 各個進(jìn)程設(shè)置隨機(jī)起點輪詢位置，如上圖的Step 1對應(yīng)的列表其起點位置指向B；
o 當(dāng)請求到達(dá)后從設(shè)置的隨機(jī)起點B位置輪詢虛擬節(jié)點列表，若輪詢到已經(jīng)初始化的虛擬節(jié)點數(shù)組的末尾（如上圖的Step2紅色箭頭指向的位置），則初始化第二批虛擬節(jié)點（如上圖Step2對應(yīng)的紅色節(jié)點），當(dāng)所有虛擬節(jié)點初始化完后將不再做初始化工作（如上圖的Step3對應(yīng)的狀態(tài)）；

此方案不僅將算法時間復(fù)雜度從 O(N) 優(yōu)化到 O(1) ，而且也避免了權(quán)重調(diào)高場景下帶來的問題。如下圖所示后端某臺機(jī)器權(quán)重從1調(diào)整為2后，其QPS平滑的增長到預(yù)期比列。

算法效果比較

在同等壓測環(huán)境下（wrk壓測工具、500并發(fā)、長連接場景、upstream配置2000個server）， Nginx 官方的 SWRR 算法CPU消耗占比高達(dá)39%（ngx_http_upstream_get_peer函數(shù)）。而 VNSWRR 算法在同等條件下CPU消耗占比只有0.27%左右（ngx_http_upstream_get_ VNSWRR 函數(shù)），顯而易見 SWRR CPU消耗要高出一個數(shù)量級。

在上述壓測環(huán)境下， Nginx 官方的 SWRR 和改進(jìn)的 VNSWRR 算法下的QPS處理能力如下圖所示：其中 VNSWRR 的QPS處理能力相對于 SWRR 算法提升60%左右。

下面我們來做個試驗，在 upstream 里配置 server 數(shù)量變化的場景下，對比 VNSWRR 和 SWRR 算法觀察 Nginx 的 QPS 處理能力以及響應(yīng)時間RT變化。

從圖中可以發(fā)現(xiàn)在 SWRR 算法下當(dāng) upstream 里面的 server 數(shù)量每增加500臺，則 Nginx 的 QPS 處理能力下降10%左右、響應(yīng)RT增長1ms左右，而在 VNSWRR 算法下 Tengine 的 QPS 處理能力及RT基本上變化不大。

到此，關(guān)于“Web服務(wù)器Tengine負(fù)載均衡算法是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>