nginx究竟使用了什么樣的負(fù)載均衡策略？
Nginx是一個開源、高性能、跨平臺的HTTP Server，也可以用作反向代理、負(fù)載均衡和HTTP緩存服務(wù)器， 很多一線互聯(lián)網(wǎng)公司用Nginx搭建分布式集群承接海量的用戶請求。
Nginx有六種負(fù)載均衡算法以滿足不同場景下的流量調(diào)度1、加權(quán)輪詢的調(diào)度算法nginx默認(rèn)情況下是輪詢調(diào)度算法，沒有指定權(quán)重(weight)下默認(rèn)是1，均勻的分發(fā)到后端每個實例上。upstream backend {
# no load balancing method is specified for Round Robin server
backend1.example.com;
server backend2.example.com;
}
如果加入權(quán)重時，根據(jù)權(quán)重比例，將流量分發(fā)到后端實例上。upstream backend {
server
backend1.example.com
weight=5;server backend2.example.com;
}
如上的配置backend1.example.com的權(quán)重被設(shè)置為 5，另一個的權(quán)重沒設(shè)置，所以是默認(rèn)值1。 所以這時候NGINX會以5：1的比例轉(zhuǎn)發(fā)請求，即6個請求中，5個被放到了 backend1.example.com上， 有一個被發(fā)到了 backend2.example.com上。
2、基于最少連接數(shù)的調(diào)度算法在這個模式下，一個請求會被 NGINX 轉(zhuǎn)發(fā)到當(dāng)前活躍請求數(shù)量最少的服務(wù)實例上：
upstream backend {
least_conn;
server backend1.example.com;
server backend2.example.com;
}
我們用least_conn來指定最少連接優(yōu)先算法, NGINX 會優(yōu)先轉(zhuǎn)發(fā)請求到現(xiàn)有連接數(shù)少的那一個服務(wù)實例上。
3、基于客戶端IP Hash的調(diào)度算法在IP Hash模式下，NGINX會根據(jù)發(fā)送請求的IP地的 hash值來決定將這個請求轉(zhuǎn)發(fā)給哪個后端服務(wù)實例。被hash 的IP地址要么是IPv4地址的前三個16進(jìn)制數(shù)或者是整個 IPv6地址。使用這個模式的負(fù)載均衡模式可以保證來自同一個 IP的請求被轉(zhuǎn)發(fā)到同一個服務(wù)實例上。當(dāng)然，這種方法在某一個后端實例發(fā)生故障時候會導(dǎo)致一些節(jié)點的訪問出現(xiàn)問題。
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
}
如果某一臺服務(wù)器出現(xiàn)故障或者無法進(jìn)行服務(wù)，我們可以給它標(biāo)記上down，這樣之前被轉(zhuǎn)發(fā)到這臺服務(wù)器上的請求就會重新進(jìn)行 hash 計算并轉(zhuǎn)發(fā)到新的服務(wù)實例上:
upstream backend {
ip_hash;
server backend1.example.com;
server backend2.example.com;
server
backend3.example.com
down;}
4、基于通用Hash的調(diào)度算法這個模式允許管理員自定義hash函數(shù)的輸入，比如:
upstream backend {
hash $reqeust_uri consistent;
server backend1.example.com;
server backend2.example.com;
}
在這個例子中，我們以請求中所帶的url為hash的輸入。 注意到這里在hash那一行的最后加入了consistent(一致性哈希)這個關(guān)鍵詞。這個關(guān)鍵詞會使用一種新的hash算法ketama, 該算法會讓管理員添加或刪除某個服務(wù)實例的時候，只有一小部分的請求會被轉(zhuǎn)發(fā)到與之前不同的服務(wù)實例上去，其他請求仍然會被轉(zhuǎn)發(fā)到原有的服務(wù)實例上去。
5、基于隨機的調(diào)度算法顧名思義，每個請求都被隨機(random)到某個服務(wù)實例上去:
upstream backend {
random;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
server backend4.example.com;
}
Random 模式還提供了一個參數(shù)two，當(dāng)這個參數(shù)被指定時，NGINX會先隨機地選擇兩個服務(wù)器(考慮 weight)，然后用以下幾種方法選擇其中的一個服務(wù)器:
1） `least_conn`: 最少連接數(shù)
2）`least_time=header(NGINX PLUS only)`: 接收到 response header 的最短平均時間
3） `least_time=last_byte(NGINX PLUS only)`: 接收到完整請求的最短平均時間
我們可以參考下面的一個例子:
upstream backend {
random two least_time=last_byte;
server backend1.example.com;
server backend2.example.com;
server backend3.example.com;
server backend4.example.com;
}
當(dāng)環(huán)境中有多個負(fù)載均衡服務(wù)器在向后端服務(wù)轉(zhuǎn)發(fā)請求時，我們可以考慮使用Random模式，在只有單個負(fù)載均衡服務(wù)器時，一般不建議使用Random模式。
6、基于最短時間的調(diào)度算法這是一個NGINX PLUS(NGINX的付費版) 才有的模式，可以將請求優(yōu)先轉(zhuǎn)發(fā)給平均響應(yīng)時間較短的服務(wù)實例，它也有三個模式:
`header`: 從服務(wù)器接收到第一個字節(jié)的時間
`last_byte`: 從服務(wù)器接收到完整的 response 的時間
`last_byte inflight`: 從服務(wù)器接收到完整地 response 的時間（考慮不完整的請求）
例子：
upstream backend {
least_time header;
server backend1.example.com;
server backend2.example.com;
}
總結(jié)NGINX提供了多種負(fù)載均衡模式，在實際使用中，需要根據(jù)實際業(yè)務(wù)需求去做嘗試，分析日志來找到最適合當(dāng)前場景的復(fù)雜均衡模式。
