nginx的 upstream模塊調度算法調度算法

<!--

• @Author: starkwang
• @Contact me: https://shudong.wang/about
• @Date: 2019-10-23 17:05:02
• @LastEditors: starkwang
• @LastEditTime: 2019-10-23 17:12:46
• @Description: nginx的 upstream模塊調度算法調度算法

-->

upstream模塊調度算法調度算法通常分爲兩類，

• 第一類爲靜態調度算法，即負載均衡器根據自身設定的規則進行分配，不須要考慮後端節點服務器的狀況，例如：rr、wrr、ip_hash等都屬於靜態調度算法。
• 第二類爲動態調度算法，即負載均衡器會根據後端節點的當前狀態來決定是否分發請求，

例如：鏈接數少的優先得到請求，響應時間短的優先得到請求。
例如：least_conn、fair等都屬於動態調度算法。下面介紹一下常見的調度算法。

本文：永久連接： https://shudong.wang/10627.html

（1）rr輪詢（默認調度算法，靜態調度算法）

按客戶端請求順序把客戶端的請求逐一分配到不一樣的後端節點服務器，
這至關於LVS中的rr算法，若是後端節點服務器宕機（默認狀況下Nginx只檢測80端口），
宕機的服務器會被自動從節點服務器池中剔除，以使客戶端的用戶訪問不受影響。新的請求會分配給正常的服務器。

（2）wrr（權重輪詢，靜態調度算法）

在rr輪詢算法的基礎上加上權重，即爲權重輪詢算法，當使用該算法時，權重和用戶訪問成正比，權重值越大，被轉發的請求也就越多。
能夠根據服務器的配置和性能指定權重值大小，有效解決新舊服務器性能不均帶來的請求分配問題。
舉個例子幫助你們加深理解。
後端服務器192.168.1.2的配置爲：E5520*2 CPU，8GB內存。
後端服務器192.168.1.3的配置爲：Xeon（TM）2.80GHz*2，4GB內存。
假設但願在有30個請求到達前端時，其中20個請求交給192.168.1.3處理，剩餘10個請求交給192.168.1.2處理，就可作以下配置；

upstream starkwang {
  server 192.168.1.2 weight=1；
  server 192.168.1.3 weight=2；
｝

權重測試的例子見前文快速實現一個簡單的負載均衡內容部分。

（3）ip_hash（靜態調度算法）

每一個請求按客戶端IP的hash結果分配，當新的請求到達時，先將其客戶端IP經過哈希算法哈希出一個值，在隨後的客戶端請求中，客戶IP的哈希值只要相同，就會被分配至同一臺服務器，該調度算法能夠解決動態網頁的session共享問題，但有時會致使請求分配不均，即沒法保證1：1的負載均衡，由於在國內大多數公司都是NAT上網模式，多個客戶端會對應一個外部IP，因此，這些客戶端都會被分配到同一節點服務器，從而致使請求分配不均。
LVS負載均衡的-p參數、Keepalived配置裏的per-sistence_timeout 50參數都相似這個Nginx裏的ip_hash參數，其功能均可以解決動態網頁的session共享問題。一樣也來看一個示例，以下：

upstream starkwang {
    ip_hash；server 192.168.1.2：80；
    server 192.168.1.3：8080；
  }
  upstream backend {    
    ip_hash；    
    server backend1.example.com；
    server backend2.example.com；   
    server backend3.example.com down；    
    server backend4.example.com；
  }

注意：當負載調度算法爲ip_hash時，後端服務器在負載均衡調度中的狀態不能有weight和backup，即便有也不會生效。

（4）fair（動態調度算法）

此算法會根據後端節點服務器的響應時間來分配請求，響應時間短的優先分配。這是更加智能的調度算法。此種算法能夠依據頁面大小和加載時間長短智能地進行負載均衡，也就是根據後端服務器的響應時間來分配請求，響應時間短的優先分配。Ng-inx自己不支持fair調度算法，若是須要使用這種調度算法，必須下載Nginx的相關模塊upstream_fair。示例以下：upstream starkwang {server 192.168.1.2；server 192.168.1.3；fair；}

（5）least_connleast_conn算法

會根據後端節點的鏈接數來決定分配狀況，哪一個機器鏈接數少就分發。
除了上面介紹的這些算法外，還有一些第三方調度算法，
例如：url_hash、一致性hash算法等。

（6）url_hash算法與ip_hash相似，

這裏是根據訪問URL的hash結果來分配請求的，讓每一個URL定向到同一個後端服務器，後端服務器爲緩存服務器時效果顯著。在upstream中加入hash語句，server語句中不能寫入weight等其餘的參數，hash_method使用的是hash算法。url_hash按訪問URL的hash結果來分配請求，使每一個URL定向到同一個後端服務器，能夠進一步提升後端緩存服務器的效率命中率。Nginx自己是不支持url_hash的，若是須要使用這種調度算法，必須安裝Nginx的hash模塊軟件包。url_hash（web緩存節點）和ip_hash（會話保持）相似。示例配置以下：

upstream starkwang {
  server squid1：3128；
  server squid2：3128；
  hash $request_uri；
  hash_method crc32；
}

（7）一致性hash算法

一致性hash算法通常用於代理後端業務爲緩存服務（如Squid、Memcached）的場景，經過將用戶請求的URI或者指定字符串進行計算，而後調度到後端的服務器上，此後任何用戶查找同一個URI或者指定字符串都會被調度到這一臺服務器上，所以後端的每一個節點緩存的內容都是不一樣的，一致性hash算法能夠解決後端某個或幾個節點宕機後，緩存的數據動盪最小，一致性hash算法知識比較複雜，詳細內容能夠參考後文或相關資料，這裏僅僅給出配置示例：

http {    
  upstream test { 
    consistent_hash $request_uri；        
    server 127.0.0.1：9001 id=1001 weight=3；        
    server 127.0.0.1：9002 id=1002 weight=10；        
    server 127.0.0.1：9003 id=1003 weight=20；    
  }}

雖然Nginx自己不支持一致性hash算法，但Nginx的分支Tengine支持。

詳細可見
http://tengine.taobao.org/doc...

做者博客

undefined