Nginx專題（2）：Nginx的負載均衡策略及其配置
- 2019 年 12 月 6 日
- 筆記
本文介紹了Nginx的負載均衡策略，一致性hash分配原理，及常用的故障節點的摘除與恢復配置。
文章來源：宜信技術學院 & 宜信支付結算團隊技術分享第一期-宜信支付結算八方數據團隊高級技術經理 周恆《Nginx的細枝末節》 分享者：宜信支付結算八方數據團隊高級技術經理 周恆 原文首發於支付結算技術團隊公號：野指針
前篇Nginx專題（1）：Nginx之反向代理及配置詳細介紹了Nginx功能之一——反向代理。本篇文章將重點介紹Nginx功能之二——負載均衡。
為了增加對負載均衡的好感，我們先了解負載均衡能實現什麼。
- 將多個伺服器節點綁定在一起提供統一的服務入口。
- 故障轉移，在意外發生的時候，可以增加一層保險，減少損失。
- 降低上線運維複雜度，實現平滑上線。運維和開發同學都喜歡。
下面正式進入主題。
一、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; }
二、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更近的數據發生了變化，但數量畢竟是有限的，減少了因為節點增加造成的影響。
三、故障節點摘除與恢復
先看看經典配置，再詳細解釋。
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節點。這是最後一個救兵了。
四、總結
由於Nginx採用了反向代理技術，對於請求的轉發有絕對的控制權，使得負載均衡變成了可能。
本文介紹了負載均衡的概念，詳細分類了Nginx的負載均衡策略，並提供了簡單配置參考。同時介紹了一致性hash的原理，及常用的故障節點的摘除與恢復。下一篇將會介紹Nginx功能之三——HTTP快取，敬請期待。
