Nginx的負載均衡策略及常用故障節(jié)點的摘除

下文給大家?guī)鞱ginx的負載均衡策略及常用故障節(jié)點的摘除，希望能夠給大家在實際運用中帶來一定的幫助，負載均衡涉及的東西比較多，理論也不多，網(wǎng)上有很多書籍，今天我們就用億速云在行業(yè)內(nèi)累計的經(jīng)驗來做一個解答。

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

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

為了增加對負載均衡的好感，我們先了解負載均衡能實現(xiàn)什么。

• 將多個云服務器節(jié)點綁定在一起提供統(tǒng)一的服務入口。
• 故障轉(zhuǎn)移，在意外發(fā)生的時候，可以增加一層保險，減少損失。
• 降低上線運維復雜度，實現(xiàn)平滑上線。運維和開發(fā)同學都喜歡。

下面正式進入主題。

一、Nginx的負載均衡策略

負載均衡就是將請求“均衡”地分配到多臺業(yè)務節(jié)點服務器上。這里的“均衡”是依據(jù)實際場景和業(yè)務需要而定的。

對于Nginx來說，請求到達Nginx，Nginx作為反向代理服務器，有絕對的決策權(quán)，可以按照規(guī)則將請求分配給它知道的節(jié)點中的一個，通過這種分配，使得所有節(jié)點需要處理的請求量處于相對平均的狀態(tài)，從而實現(xiàn)負載均衡。

Nginx支持的負載均衡策略很多，比較重點的如下：

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

這么多的策略，非常不利于記憶和選擇，我們不妨將這些常見的策略歸類，分而化之，方便挑選。

第一類 最佳實現(xiàn)

• weight(權(quán)重)
• 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;
}

第二類 性能優(yōu)先

• weight(權(quán)重)
• fair(按響應時長，三方插件)
• least_conn(最少連接數(shù))

讓業(yè)務節(jié)點中性能更強的機器得到更多請求，這也是一個比較好的分配策略。

什么是性能更好的機器？這個問題也有很多的維度去考量。

• 從經(jīng)驗或硬件上分為高權(quán)重、低權(quán)重的機器。
• 按照節(jié)點請求的響應時長來決定是多分配請求，還是少分配請求。
• 按照保持的連接數(shù)。一般來說保持的連接數(shù)越多說明處理的任務越多，也是最繁忙的，可以將請求分配給其他機器處理。

權(quán)重的配置參考：

upstream server_group {
    server backend1.example.com weight=5;
    #默認為不配置權(quán)重為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;
}

最少連接數(shù)(least_conn)配置參考：

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

第三類 保持穩(wěn)定

• ip_hash
• url_hash

很多請求都是有狀態(tài)的，上一次請求到哪個業(yè)務節(jié)點，這次還要請求到哪臺機器。比如常見的session就是這樣一種有狀態(tài)的業(yè)務。

這里Nginx提供了按照客戶端ip的hash來作為用戶的標示分配、url的hash作為分配標示的規(guī)則。本質(zhì)上還是要找到用戶的請求中不變的要素，抽離出來，這樣就可以進行分配了。

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？為什么要引入這個機制？在生產(chǎn)環(huán)境下，業(yè)務節(jié)點經(jīng)常會出現(xiàn)增加或減少的情況，就算這種增加或減少都是被動的，也可能會對hash分配產(chǎn)生影響。如何能夠做到盡量減少影響呢？這時一致性hash被發(fā)明出來。

一致性hash解決兩個問題：

• 分配特別不均勻；
• 節(jié)點變動除了對分配到這個節(jié)點上的請求有影響，還會導致其他節(jié)點上的請求重新分配。

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

將原來的每一個節(jié)點復制出N個虛擬節(jié)點，并且給這些虛擬節(jié)點都起個名字。

比如原來有5個節(jié)點，分配的時候經(jīng)常會不均勻，現(xiàn)在每個節(jié)點都虛擬出N個節(jié)點，就是5*N個節(jié)點，會極大降低分配不均勻的情況。下面就要說說如何分配的問題了。

2）如何解決節(jié)點變動的問題

一致性哈希的基本思想：

• 定義一個[0,(2^32)-1]的數(shù)值空間。相當于取長度從 0到2^32-1 的線段。
• 節(jié)點映射到線段上。將每個節(jié)點，包括虛擬節(jié)點，都通過hash算法得到數(shù)值，然后映射到這個取值區(qū)間上。

如下圖。

• 計算數(shù)據(jù)的Hash值。把請求中的關(guān)鍵字符串通過hash算法得到一個數(shù)值，在線段中找到一個位置，如果算出來的數(shù)值大于2^32-1則認為是0。按照這個規(guī)則，其實是把這個線段首尾相連形成一個環(huán)，所以也叫hash環(huán)。
• 數(shù)據(jù)節(jié)點在線段上找歸屬的節(jié)點。沿著這個線段向右找到離得最近的節(jié)點，并把該節(jié)點作為這個數(shù)據(jù)的歸屬節(jié)點。

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

• 節(jié)點減少：比如NodeA突然故障了，原來分配到其他節(jié)點上的數(shù)據(jù)不會發(fā)生變化，只有分配到NodeA上的數(shù)據(jù)會重新找離它們最近的點，從而減少了hash重新分配的數(shù)量。這也是一致性hash最大的優(yōu)勢。
• 節(jié)點增加：比如現(xiàn)在請求量抖增，需要增加節(jié)點降低負載。當新加入節(jié)點NodeE時，NodeE及它的一群虛擬節(jié)點會根據(jù)hash值分配在hash環(huán)上。這時，大部分數(shù)據(jù)再根據(jù)一致性哈希規(guī)則找其歸屬的Node節(jié)點都不會發(fā)生變化，只有那些值計算出來發(fā)現(xiàn)離NodeE更近的數(shù)據(jù)發(fā)生了變化，但數(shù)量畢竟是有限的，減少了因為節(jié)點增加造成的影響。

三、故障節(jié)點摘除與恢復

先看看經(jīng)典配置，再詳細解釋。

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

這個參數(shù)決定了多少次請求后端失敗后會暫停這個業(yè)務節(jié)點，不再給它發(fā)新的請求，默認值是1。此參數(shù)需要配合fail_timeout一起用。

題外話：如何定義失敗，有很多種類型，這里因為主要處理HTTP代理，所以更關(guān)注proxy_next_upstream。

proxy_next_upstream：主要定義了當服務節(jié)點出現(xiàn)狀況時，會將請求發(fā)給其他節(jié)點，也就是定義了怎么算作業(yè)務節(jié)點失敗。

fail_timeout=time

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

把上面兩個參數(shù)聯(lián)合起來考慮就是：當Nginx發(fā)現(xiàn)發(fā)送到這個節(jié)點上的請求失敗了3次的時候，就會把這個節(jié)點摘除，摘除時間是30s，30s后才會再次發(fā)送請求到這個節(jié)點上。

backup

類似于switch語句中的default，當主要節(jié)點都掛了的時候，會把請求打到這個backup節(jié)點。這是最后一個救兵了。

看了以上Nginx的負載均衡策略及常用故障節(jié)點的摘除的解答，如果大家還有什么地方需要了解的可以在億速云行業(yè)資訊里查找自己感興趣的或者找我們的專業(yè)技術(shù)工程師解答的，億速云技術(shù)工程師在行業(yè)內(nèi)擁有十幾年的經(jīng)驗了。億速云官網(wǎng)鏈接www.kemok4.com