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