輪詢
nginx將所有請求均勻的分給集群中的每臺服務器。
upstream?test?{ server?127.0.0.1:7001;?#?等同于server?127.0.0.1:7001?weight=1;server?150.109.118.85:7001;?#?等同于server?150.109.118.85:7001?weight=1;} server?{ listen?8081; server_name?localhost; location?/?{ ?proxy_pass?http://test/; } }
upstream：定義一個服務集群。 proxy_pass: 將匹配的請求代理轉發到proxy_pass后面配置的服務上，這里因為需要配置負載均衡，所以這里http://后面必須要跟上upstream定義的服務集群。
注意：upstream定義服務集群時，配置的服務地址只能是域名+端口或者ip+端口，不能帶有協議和路徑，否則nginx會報nginx: [emerg] invalid host in upstream這個錯誤信息。
加權（weight）
upstream?test?{ server?127.0.0.1:7001?weight=2; server?150.109.118.85:7001?weight=1; }
前面兩次請求都會轉發到127.0.0.1:7001這個服務，后面一次請求會轉發到150.109.118.85:7001這個服務，再后面兩次轉發到127.0.0.1:7001，。。。
最少連接數
文件位置：src/http/modules/ngx_http_upstream_least_conn_module.c
nginx請求分配給active_connection/weight最小的服務器。
upstream?test?{ ??least_conn; server?127.0.0.1:7001?weight=1; server?150.109.118.85:7001?weight=1; }
ip_hash
文件位置：src/http/modules/ngx_http_upstream_ip_hash_module.c
根據用戶的ip，計算出一個hash值，如果負載均衡緩存中有這個hash對應的服務器，那就直接轉發到對應的服務器上。
upstream?test?{ ??ip_hash; server?127.0.0.1:7001; server?150.109.118.85:7001; }
nginx使用ip_hash策略后，只要用戶電腦的ip不變化，就會始終請求同一臺業務服務。
應用場景：在實現文件上傳功能時，要實現一個大文件上傳，往往會將這個大文件分成多個片段，然后上傳到服務器，如果使用前面給的策略，就會出現同一個文件的分片被上傳到不同服務器，導致文件合并失敗，不能達到預期效果。nginx使用ip_hash策略后，客戶端只要上傳了當前文件的一個片段，后續文件片段上傳的時候，nginx通過計算ip的hash，自動把請求轉發到hash對應的服務器。
hash
文件位置：src/http/modules/ngx_http_upstream_hash_module.c
可以進行hash計算的有remote_addr（客戶端ip）（從測試結果上面看感覺可以直接替換掉ip_hash）、request_uri(請求uri)、args（請求參數），下面主要以request_uri的使用作為展示，其他兩個使用都類似。
根據請求的uri計算出一個hash值，然后將該請求轉發到一臺服務器上面，后續請求通過hash計算后，如果有相同的hash，那么就會將該請求轉發到該hash對應的服務器。
假設集群中某臺服務器宕機后會發生什么情況：如果r1命中a服務器，r2會命中哪個服務器？。如果a服務器宕機，之前通過r1計算出來的哈希值與a服務器的對應關系會失效，并且r1會重新分發給b服務器。后續a服務器恢復正常后，r1還是會分配給b服務器。
upstream?test?{ ??hash?$request_uri; server?127.0.0.1:7001; server?150.109.118.85:7001; }
應用場景：所有請求相同的文件資源的請求都會被轉發到同一個服務器，資源更容易命中緩存，減少寬帶和資源下載時間。
consistent_hash
consistent_hash（一致性hash）這個模塊使用方式和nginx內置的hash模塊幾乎相同。能夠使用consistent_hash進行計算的內容和前面提到的nginx內置的hash模塊一樣，有remote_addr、request_uri、args。您可以在這里下載 ngx_http_consistent_hash，它是一個用于三方模塊的軟件。
upstream?test?{ consistent_hash?$request_uri; server?127.0.0.1:7001; server?150.109.118.85:7001; }
fair
響應時間短的服務優先分配請求。您可以在nginx_upstream_fair的下載頁面獲取該三方模塊。這個模塊上次更新是8年前，可能需要考慮下是否需要使用這個。
upstream?test?{ fair; server?127.0.0.1:7001; server?150.109.118.85:7001; }
測試中得出效果和輪詢默認情況效果一樣，暫時沒有找到問題在哪。。。
負載均衡相關參數
down
標識down的服務器暫時不支持資源請求。
upstream?test?{ server?127.0.0.1:7001?down; server?150.109.118.85:7001; }
上面負載均衡的例子中，因為127.0.0.1:7001標識為down，所以不會有請求轉發到這個服務，所有的請求都會轉發到150.109.118.85:7001這個服務。
weight
集群中服務的權重值，默認是1。在只有weight這一個影響條件下，且集群中服務都正常，nginx會將更多的請求轉發到weight更大的服務。
upstream?test?{ server?127.0.0.1:7001?weight=2; server?150.109.118.85:7001?weight=1; }
這個集群中127服務和150服務各處理的請求比例為2:1。
max_fails
允許服務處理請求時服務出錯的次數，默認為1。當服務處理請求發生錯誤的次數超過max_fails時，后面的請求暫時不會轉發到這臺發生錯誤的服務。
upstream?test?{ server?127.0.0.1:7001?max_fail=1; server?150.109.118.85:7001; }
fail_timeout
如果某個服務處理請求時發生錯誤的次數超過 max_fails，nginx 將暫時禁止將請求轉發到該服務。當過去fail_timeout設置的時間以后，nginx會嘗試將請求轉發到剛才被禁止的服務，如果服務正常，那么后續的請求可以繼續轉發到這臺服務，如果服務錯誤，那么繼續等待fail_timeout時間后再來檢測。fail_timeout默認時間是10s。
upstream?test?{ server?127.0.0.1:7001?max_fail=1?fail_timeout=10s; server?150.109.118.85:7001; }
backup
備用服務器，當所有非backup服務發生錯誤被停用或者設置為down時，nginx會啟用標識為backup的服務。
upstream?test?{ server?127.0.0.1:7001?backup; server?150.109.118.85:7001; }
max_conns
這個功能存在于nginx商業版。同一服務同時處理請求的個數。防止服務因處理請求過多，服務器性能不足，發生宕機的情況。
upstream?test?{ server?127.0.0.1:7001?max_conns=10000; server?150.109.118.85:7001; }
slow_start
這個功能存在于nginx商業版。當集群中錯誤服務等待fail_timeout時間后，nginx檢測到這個服務能夠正常使用后，再等待slow_start時間后，才正式使用這個服務。
upstream?test?{ server?127.0.0.1:7001?slow_start=30s; server?150.109.118.85:7001; }
