nginx負載平衡怎麼配置

輪詢

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;
}

以上是nginx負載平衡怎麼配置的詳細內容。更多資訊請關注PHP中文網其他相關文章！