技術標籤：Linuxnginxnginx負載均衡

這裡簡單介紹一下nginx負載均衡相關知識nginx1.18

首先啟動兩個相同的專案我這裡啟動兩個192.168.3.45:8090/mall-api 與192.168.3.45:8190/mall-api （本機測試開兩個埠模擬多伺服器）

#負載均衡
    upstream app-api {
        server 192.168.3.45:8090;#等同於192.168.3.45:8090 weight=1
        server 192.168.3.45:8190;#等同於192.168.3.45:8190 weight=1
    }
    server {
        listen       80;
        server_name  localhost;

        location /mall-api {
            add_header backendIp $upstream_addr;#方便追蹤檢視nginx分發請求地址
            add_header backendCode $upstream_status;#方便追蹤檢視nginx分發請求地址
            proxy_buffering off;
            proxy_pass http://app-api;
        }
        ...........後面內容省略.............
    }
 

upstream：定義一個服務叢集。
proxy_pass: 將匹配的請求代理轉發到proxy_pass後面配置的服務上，這裡因為需要配置負載均衡，所以這裡http://後面必須要跟上upstream定義的服務叢集。

注意：upstream定義服務叢集時，配置的服務地址只能是域名+埠或者ip+埠，不能帶有協議和路徑，否則nginx會報nginx: [emerg] invalid host in upstream這個錯誤資訊。

配置完成後執行./nginx -s reload ./nginx -s stop ./nginx重新載入和啟動nginx

然後請求可檢視，伺服器192.168.3.45:80/mall-api埠的請求會在192.168.3.45:8190/mall-api和192.168.3.45:8090/mall-api切換。

注意：proxy_pass和location配合的用法

(1) proxy_pass URL;：定義反向代理到的路徑，適用範圍：location, if in location, limit_except上下文中；URL為完整的路徑

匹配location後傳遞給後端請求路徑情況解析( REMOTE-IP:後端主機IP地址)：

1)proxy_pass後面的路徑不帶uri地址時，其會將location的uri地址直接傳遞給後端的主機(直接補充關係)；

location /test/{

proxy_passhttp://REMOTE-IP;

}

此時傳遞給後端的請求路徑為：http://REMOTE-IP/test/

2)proxy_pass後面的路徑是一個uri時，其會將location的test地址替換為後端主機自己的new-test(對映關係)；

location /test/{

proxy_passhttp://REMOTE-IP/new-test/;

}

此時客戶端請求被location的/test/匹配到，跳轉到後端請求路徑將由/new-test/替換/test/：http://REMOTE-IP/new-test/

加權（weight）策略

upstream test {
	server 192.168.3.45:8090 weight=2;
	server 192.168.3.45:8190 weight=1;
}

前面兩次請求都會轉發到8090這個服務，後面一次請求會轉發到8190這個服務，再後面兩次轉發到8090。。

最少連線數

nginx請求分配給active_connection/weight最小的伺服器。

upstreamtest{
	least_conn;
	server192.168.3.45:8090weight=1;
	server192.168.3.45:8091weight=1;
}

ip_hash

根據使用者的ip，計算出一個hash值，如果負載均衡快取中有這個hash對應的伺服器，那就直接轉發到對應的伺服器上。

upstreamtest{
	ip_hash;
	server192.168.3.45:8090;
	server192.168.3.45:8190;
}

nginx使用ip_hash策略後，只要使用者電腦的ip不變化，就會始終請求同一臺業務服務。

應用場景：在實現檔案上傳功能時，要實現一個大檔案上傳，往往會將這個大檔案分成多個片段，然後上傳到伺服器，如果使用前面給的策略，就會出現同一個檔案的分片被上傳到不同伺服器，導致檔案合併失敗，不能達到預期效果。nginx使用ip_hash策略後，客戶端只要上傳了當前檔案的一個片段，後續檔案片段上傳的時候，nginx通過計算ip的hash，自動把請求轉發到hash對應的伺服器。

hash

可以進行hash計算的有remote_addr（客戶端ip）（從測試結果上面看感覺可以直接替換掉ip_hash）、request_uri(請求uri)、args（請求引數），下面主要以request_uri的使用作為展示，其他兩個使用都類似。

根據請求的uri計算出一個hash值，然後將該請求轉發到一臺伺服器上面，後續請求通過hash計算後，如果有相同的hash，那麼就會將該請求轉發到該hash對應的伺服器。

如果叢集中某臺伺服器宕機之後會出現什麼情況：假設r1命中a伺服器；r2命中b伺服器。當a伺服器宕機，之前通過r1計算出來的hash與a伺服器的對應情況會失效，r1將重新分配給b伺服器。後續a伺服器恢復正常後，r1還是會分配給b伺服器。

upstreamtest{
	hash$request_uri;
	server192.168.3.45:8090;
	server192.168.3.45:8190;
}

應用場景：所有請求相同的檔案資源的請求都會被轉發到同一個伺服器，資源更容易命中快取，減少寬頻和資源下載時間。

consistent_hash

consistent_hash（一致性hash）這個模組使用方式和nginx內建的hash模組幾乎相同。能夠使用consistent_hash進行計算的內容和前面提到的nginx內建的hash模組一樣，有remote_addr、request_uri、args。這是一個三方模組，可以在ngx_http_consistent_hash這裡下載。

upstreamtest{
	consistent_hash$request_uri;
	server192.168.3.45:8090;
	server192.168.3.45:8190;
}

負載均衡相關引數

down

標識down的伺服器暫時不支援資源請求。

upstreamtest{
	server192.168.3.45:8090down;
	server192.168.3.45:8190;
}

上面負載均衡的例子中，因為192.168.3.45:8090標識為down，所以不會有請求轉發到這個服務，所有的請求都會轉發到192.168.3.45:8190這個服務。

weight

叢集中服務的權重值，預設是1。在只有weight這一個影響條件下，且叢集中服務都正常，nginx會將更多的請求轉發到weight更大的服務。

upstreamtest{
	server192.168.3.45:8090weight=2;
	server192.168.3.45:8190weight=1;
}

這個叢集中127服務和150服務各處理的請求比例為2:1。

max_fails

允許服務處理請求時服務出錯的次數，預設為1。當服務處理請求發生錯誤的次數超過max_fails時，後面的請求暫時不會轉發到這臺發生錯誤的服務。

upstreamtest{
	server192.168.3.45:8090max_fail=1;
	server192.168.3.45:8190;
}

fail_timeout

當服務處理請求發生錯誤的次數超過max_fails以後，nginx會暫時禁止將請求轉發到這個服務。當過去fail_timeout設定的時間以後，nginx會嘗試將請求轉發到剛才被禁止的服務，如果服務正常，那麼後續的請求可以繼續轉發到這臺服務，如果服務錯誤，那麼繼續等待fail_timeout時間後再來檢測。fail_timeout預設時間是10s。

upstreamtest{
	server192.168.3.45:8090max_fail=1fail_timeout=10s;
	server192.168.3.45:8190;
}

backup

備用伺服器，當所有非backup服務發生錯誤被停用或者設定為down時，nginx會啟用標識為backup的服務。

upstreamtest{
	server192.168.3.45:8090backup;
	server192.168.3.45:8190;
}

max_conns

這個功能存在於nginx商業版。同一服務同時處理請求的個數。防止服務因處理請求過多，伺服器效能不足，發生宕機的情況。

upstreamtest{
	server192.168.3.45:8090max_conns=10000;
	server192.168.3.45:8190;
}

slow_start

這個功能存在於nginx商業版。當叢集中錯誤服務等待fail_timeout時間後，nginx檢測到這個服務能夠正常使用後，再等待slow_start時間後，才正式使用這個服務。

upstreamtest{
	server192.168.3.45:8090slow_start=30s;
	server192.168.3.45:8190;
}