QPS 相比 Nginx 提高60%，阿里 Tengine 負載均衡算法揭祕

前言

在阿里七層流量入口接入層（Application Gateway）場景下， Nginx 官方的Smooth Weighted Round-Robin（ SWRR ）負載均衡算法已經沒法再完美施展它的技能。 Tengine 經過實現新的負載均衡算法Virtual Node Smooth Weighted Round-Robin（VNSWRR ）不只優雅的解決了 SWRR 算法的缺陷，並且QPS處理能力相對於 Nginx 官方的 SWRR 算法提高了60%左右。

問題

接入層 Tengine 經過自研的動態 upstream 模塊實現動態服務發現，即運行時動態感知後端應用機器擴縮容、權重調整和健康檢查等信息。同時該功能能夠作不少事情，好比用戶可經過調整後端應用某臺機器的權重從而達到線上真實引流壓測目的。然而，這些操做在 Nginx 原生 SWRR 算法下卻可能引發不可逆轉的血案。

• 在接入層（Application Gateway）場景下， Nginx 的負載均衡算法 SWRR 會致使權重被調高機器的QPS瞬間暴漲，如上圖App2-host-A機器當權重調整爲2時，某一時刻流量會集中轉發到該機器；

• Nginx 的 SWRR 算法的處理時間複雜度是O(N)，在大規模後端場景下 Nginx 的處理能力將線性降低；

綜上所述，對接入層 Tengine 的負載均衡轉發策略的改造及性能優化已迫在眉睫。

原生 SWRR 算法分析

在介紹案列以前，咱們先簡單介紹下 Nginx 的負載均衡算法 SWRR 轉發策略及特色：

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

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

假設有3臺機器A、B、C權重分別爲五、一、1，其中數組s表明機器列表、n表明機器數量，每一個機器的cw初始化爲0、ew初始化爲機器權重、tw表明本輪選擇中全部機器的ew之和、best表示本輪被選中的機器。簡單的描述就是每次選擇機器列表中cw值最大的機器，被選中機器的cw將會減去tw，從而下降下次被選中的機會，簡單的僞代碼描述以下：

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;

請求編號 選擇前的權重值 被選中的server 選擇後的權重值
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算法特色：平滑、分散 。

調高權重引起的血案

從上面的描述來看， SWRR 算法彷佛已經比較完美了，可是在某些場景下仍是有必定的缺陷，下面咱們就一個真實的案列來看看它都有哪些缺陷：

一天早上，流量調度的同窗匆忙的跑到個人工位，當時看他神色是尤其的緊張，心想確定是出啥問題了。果不其然："爲啥我把中心機房某臺機器的權重從1調整爲2的時候，接入層 Tengine 並非按照這個權重比例轉發流量恩？"，當時被調高機器QPS變化趨勢以下圖所示：

注：其中深藍色曲線表示權重被調高機器的QPS變化，淺綠色曲線表示該集羣單機的平均QPS。

當時看到這個流量趨勢變化圖的時候也是一臉茫然，不過好在有圖有數據，那就能夠先分析一下這個圖的幾個特徵數字；因爲部分數據敏感，詳細數據分析就不在此處展開。直接描述其現象和緣由：

被調高權重的機器當時被分發到的流量基本上是該應用機房總流量的1/2，一段時間後該機器的流量才恢復到預期的權重比例。其緣由就是因爲接入層 Tengine 對後端機器信息的變化是動態感知熱生效的，而 Nginx 官方的 SWRR 算法策略第一次會選擇當前機器列表中權重最大的機器轉發流量。從而進一步致使已感知到後端機器權重變化的接入層 Tengine 都會將第一個請求轉發到權重被調高的機器上。

大規模下性能驟降

以下是在upstream裏面配置2000個後端，在反向代理場景下壓測 Nginx 的函數熱點圖以下所示。其中ngx_http_upstream_get_peer函數CPU消耗佔比高達39%，其緣由是由於 SWRR 算法的選取機器的時間複雜度爲O(N) (其中N表明後端機器數量)，這就至關於每一個請求都要執行接近2000次循環才能找到對應本次轉發的後端機器。

• 壓測環境

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

Tengine 核心配置：配置2個worker進程，壓力源 --長鏈接-->  Tengine / Nginx  --短鏈接--> 後端

下面咱們作個試驗，控制變量是 upstream 裏面配置的 server 數量，觀察不一樣場景下 Nginx 的 QPS 處理能力以及響應時間RT變化狀況。從圖中能夠發現當後端 upstream 裏面的 server 數量每增長500臺則 Nginx 的 QPS 處理能力降低 10% 左右，響應RT增加 1ms 左右。

從上面的分析基本上已經確認是 SWRR 算法存在如上兩個缺陷，下面就開始解決；

改進的 VNSWRR 算法

雖然經典的WRR算法（如隨機數方式實現）能夠在時間複雜度上達到 O(1) ，並且也能夠避免 SWRR 算法調高權重的選取缺陷。可是在某些場景下（如小流量）可能形成後端的流量不均等問題，尤爲是在流量瞬間暴漲的場景下有太多不可肯定性。因而就構思是否有一種算法即能擁有 SWRR 算法的平滑、分散特色，又能具有 O(1) 的時間複雜度。因此就有了Virtual Node Smooth Weighted Round-Robin（ VNSWRR ）算法。

此處拿個列子來講明此算法：3臺機器A、B、C權重分別爲一、二、3，N表明後端機器數 、TW表明後端機器權重總和。

算法關鍵點

o 虛擬節點初始化順序嚴格按照 SWRR 算法選取，保證初始化列表裏的機器可以分佈足夠散列；
o 虛擬節點運行時分批初始化，避免密集型計算集中。每批次虛擬節點使用完後再進行下一批次虛擬節點列表初始化，每次只初始化min(n, max)個虛擬節點；

算法描述

o Tengine 程序啓動或者運行時感知後端機器信息變化時，則構建TW個虛擬節點且第一次只初始化N個節點（注：TW表明後端機器權重之和，N表明後端機器數）；
o 各個進程設置隨機起點輪詢位置，如上圖的Step 1對應的列表其起點位置指向B；
o 當請求到達後從設置的隨機起點B位置輪詢虛擬節點列表，若輪詢到已經初始化的虛擬節點數組的末尾（如上圖的Step2紅色箭頭指向的位置），則初始化第二批虛擬節點（如上圖Step2對應的紅色節點），當全部虛擬節點初始化完後將再也不作初始化工做（如上圖的Step3對應的狀態）；

此方案不只將算法時間複雜度從 O(N) 優化到 O(1) ，並且也避免了權重調高場景下帶來的問題。以下圖所示後端某臺機器權重從1調整爲2後，其QPS平滑的增加到預期比列。

算法效果比較

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

在上述壓測環境下， Nginx 官方的 SWRR 和改進的 VNSWRR 算法下的QPS處理能力以下圖所示：其中 VNSWRR 的QPS處理能力相對於 SWRR 算法提高60%左右。

下面咱們來作個試驗，在 upstream 裏配置 server 數量變化的場景下，對比 VNSWRR 和 SWRR 算法觀察 Nginx 的 QPS 處理能力以及響應時間RT變化。

從圖中能夠發如今 SWRR 算法下當 upstream 裏面的 server 數量每增長500臺，則 Nginx 的 QPS 處理能力降低10%左右、響應RT增加1ms左右，而在 VNSWRR 算法下 Tengine 的 QPS 處理能力及RT基本上變化不大。

總結

正是這種大流量場景下才暴露出 Nginx 的一些問題，所謂業務與技術相輔相成，業務可促使新的技術誕生、新的技術賦能創造新的業務。 VNSWRR 算法即擁有 SWRR 算法的平滑、分散特色，也避免了其缺陷。同時在新算法下時間複雜度也從 O(N) 調整爲 O(1) ，在大規模場景下 VNSWRR 的QPS處理能力相對於 Nginx 官方的 SWRR 算法提高60%左右。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。