Nginx專題（2）：Nginx的負載均衡策略及其配置

摘要：本文介紹了Nginx的負載均衡策略，一致性hash分配原理，及經常使用的故障節點的摘除與恢復配置。

文章來源：宜信技術學院 & 宜信支付結算團隊技術分享第一期-宜信支付結算八方數據團隊高級技術經理 周恆《Nginx的細枝末節》

分享者：宜信支付結算八方數據團隊高級技術經理 周恆

原文首發於支付結算技術團隊公號：野指針

前篇Nginx專題（1）：Nginx之反向代理及配置詳細介紹了Nginx功能之一——反向代理。本篇文章將重點介紹Nginx功能之二——負載均衡。

爲了增長對負載均衡的好感，咱們先了解負載均衡能實現什麼。

• 將多個服務器節點綁定在一塊兒提供統一的服務入口。
• 故障轉移，在乎外發生的時候，能夠增長一層保險，減小損失。
• 下降上線運維複雜度，實現平滑上線。運維和開發同窗都喜歡。

下面正式進入主題。

1、Nginx的負載均衡策略

負載均衡就是將請求「均衡」地分配到多臺業務節點服務器上。這裏的「均衡」是依據實際場景和業務須要而定的。

對於Nginx來講，請求到達Nginx，Nginx做爲反向代理服務器，有絕對的決策權，能夠按照規則將請求分配給它知道的節點中的一個，經過這種分配，使得全部節點須要處理的請求量處於相對平均的狀態，從而實現負載均衡。

Nginx支持的負載均衡策略不少，比較重點的以下：

• round robin(輪詢)
• random(隨機)
• weight(權重)
• fair(按響應時長，三方插件)
• url_hash(url的hash值)
• ip_hash(ip的hash值)
• least_conn(最少鏈接數)

這麼多的策略，很是不利於記憶和選擇，咱們不妨將這些常見的策略歸類，分而化之，方便挑選。

第一類 最佳實現

• weight(權重)
• random(隨機)

最佳實踐，其實就是最多見、最普通的默認配置，固然也是在必定程度上最好用的配置。不知道用什麼方式的時候，就能夠選擇用這一類型。

輪詢不用多說。這裏的隨機，其實在大量請求的狀況下，按照機率的理論等同於輪詢的方式。

輪詢配置參考：

#默認配置就是輪詢策略
upstream server_group {
   server backend1.example.com;
   server backend2.example.com;
}

隨機配置參考：

upstream server_group { 
   random; 
   server backend1.example.com; 
   server backend2.example.com; 
   server backend3.example.com; 
   server backend4.example.com;
}

第二類 性能優先

• weight(權重)
• fair(按響應時長，三方插件)
• least_conn(最少鏈接數)

讓業務節點中性能更強的機器獲得更多請求，這也是一個比較好的分配策略。

什麼是性能更好的機器？這個問題也有不少的維度去考量。

• 從經驗或硬件上分爲高權重、低權重的機器。
• 按照節點請求的響應時長來決定是多分配請求，仍是少分配請求。
• 按照保持的鏈接數。通常來講保持的鏈接數越多說明處理的任務越多，也是最繁忙的，能夠將請求分配給其餘機器處理。

權重的配置參考：

upstream server_group {
    server backend1.example.com weight=5;
    #默認爲不配置權重爲1
    server backend2.example.com;
}

響應的時長(fair)配置參考：須要在Nginx編譯時加入nginx-upstream-fair模塊。

upstream server_group{
   fair;
   server backend1.example.com; 
   server backend2.example.com; 
   server backend3.example.com; 
   server backend4.example.com;
}

最少鏈接數(least_conn)配置參考：

upstream server_group {
    least_conn;
    server backend1.example.com;
    server backend2.example.com;
}

第三類 保持穩定

• ip_hash
• url_hash

不少請求都是有狀態的，上一次請求到哪一個業務節點，此次還要請求到哪臺機器。好比常見的session就是這樣一種有狀態的業務。

這裏Nginx提供了按照客戶端ip的hash來做爲用戶的標示分配、url的hash做爲分配標示的規則。本質上仍是要找到用戶的請求中不變的要素，抽離出來，這樣就能夠進行分配了。

ip_hash配置參考：

upstream server_group {
    ip_hash;
    server backend1.example.com;
    server backend2.example.com;
}

url_hash配置參考：

upstream server_group{
   hash $request_uri consistent;
   server backend1.example.com; 
   server backend2.example.com; 
   server backend3.example.com; 
   server backend4.example.com;
}

2、Nginx支持一致性哈希進行分配

Nginx支持一致性hash進行分配，也就是配置中consistent。

什麼是一致性hash？爲何要引入這個機制？在生產環境下，業務節點常常會出現增長或減小的狀況，就算這種增長或減小都是被動的，也可能會對hash分配產生影響。如何可以作到儘可能減小影響呢？這時一致性hash被髮明出來。

一致性hash解決兩個問題：

• 分配特別不均勻；
• 節點變更除了對分配到這個節點上的請求有影響，還會致使其餘節點上的請求從新分配。

1）如何解決分配不均的問題

將原來的每個節點複製出N個虛擬節點，而且給這些虛擬節點都起個名字。

好比原來有5個節點，分配的時候常常會不均勻，如今每一個節點都虛擬出N個節點，就是5*N個節點，會極大下降分配不均勻的狀況。下面就要說說如何分配的問題了。

2）如何解決節點變更的問題

一致性哈希的基本思想：

• 定義一個[0,(2^32)-1]的數值空間。至關於取長度從 0到2^32-1 的線段。
• 節點映射到線段上。將每一個節點，包括虛擬節點，都經過hash算法獲得數值，而後映射到這個取值區間上。

以下圖。

• 計算數據的Hash值。把請求中的關鍵字符串經過hash算法獲得一個數值，在線段中找到一個位置，若是算出來的數值大於2^32-1則認爲是0。按照這個規則，實際上是把這個線段首尾相連造成一個環，因此也叫hash環。
• 數據節點在線段上找歸屬的節點。沿着這個線段向右找到離得最近的節點，並把該節點做爲這個數據的歸屬節點。

下面再來看節點的變化對一致性Hash的影響。

• 節點減小：好比NodeA忽然故障了，原來分配到其餘節點上的數據不會發生變化，只有分配到NodeA上的數據會從新找離它們最近的點，從而減小了hash從新分配的數量。這也是一致性hash最大的優點。
• 節點增長：好比如今請求量抖增，須要增長節點下降負載。當新加入節點NodeE時，NodeE及它的一羣虛擬節點會根據hash值分配在hash環上。這時，大部分數據再根據一致性哈希規則找其歸屬的Node節點都不會發生變化，只有那些值計算出來發現離NodeE更近的數據發生了變化，但數量畢竟是有限的，減小了由於節點增長形成的影響。

3、故障節點摘除與恢復

先看看經典配置，再詳細解釋。

upstream server_group {
    server backend1.example.com ;
    server backend2.example.com  max_fails=3 fail_timeout=30s;
    server backup1.example.com  backup;
}

max_fails=number

這個參數決定了多少次請求後端失敗後會暫停這個業務節點，再也不給它發新的請求，默認值是1。此參數須要配合fail_timeout一塊兒用。

題外話：如何定義失敗，有不少種類型，這裏由於主要處理HTTP代理，因此更關注proxy_next_upstream。

proxy_next_upstream：主要定義了當服務節點出現情況時，會將請求發給其餘節點，也就是定義了怎麼算做業務節點失敗。

fail_timeout=time

決定了當Nginx認定這個節點不可用時，暫停多久。不配置默認就是10s。

把上面兩個參數聯合起來考慮就是：當Nginx發現發送到這個節點上的請求失敗了3次的時候，就會把這個節點摘除，摘除時間是30s，30s後纔會再次發送請求到這個節點上。

backup

相似於switch語句中的default，當主要節點都掛了的時候，會把請求打到這個backup節點。這是最後一個救兵了。

4、總結

因爲Nginx採用了反向代理技術，對於請求的轉發有絕對的控制權，使得負載均衡變成了可能。

本文介紹了負載均衡的概念，詳細分類了Nginx的負載均衡策略，並提供了簡單配置參考。同時介紹了一致性hash的原理，及經常使用的故障節點的摘除與恢復。下一篇將會介紹Nginx功能之三——HTTP緩存，敬請期待。