轉身吶喊妳
這個問題問得可就有點門外漢的意思了。。。
nginx作為一款負載均衡服務組件，憑藉其近乎絕對穩定，性能優異等特性，成為企業級大應用中不可或缺的均衡工具！
nginx使用反向代理實現，在訪問者(通常為瀏覽器)與應用服務器之間進行解耦，將收到的請求通過一定的負載均衡策略分配到不同的應用服務器上，原本使用一臺服務器提供服務，現在通過這樣的nginx集群應用服務，對外提供強大的，透明的服務，單一應用服務器的不穩定性也可完美解決！
由此可見，nginx是對外提供負載均衡的服務組件，可提供的負載均衡策略包括但不限於以下幾種:
1，輪詢:每臺應用服務器平均的接受到請求。
默認方式:只要通過server配置了多臺應用服務器，就能默認輪詢！
2，weight:按照一定的權重，分配到不同的機器上不同的訪問數。
通過weight＝4;這樣的句式來配置！
3，ip_hash:通過ip進行hash進行訪問服務器分配，可解決上訴輪詢的session不在一臺機器的情況
使用ip_hash開啟！
4，fair:按照應用服務的響應時間動態分配服務器。
5，url_hash:通過url進行hash分配到應用服務器上。
一般選擇那種負載均衡方式還需要通過業務，整個架構來確定，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提供了多種負載均衡模式，在實際使用中，需要根據實際業務需求去做嘗試，分析日誌來找到最適合當前場景的複雜均衡模式。
