Nginx負(fù)載均衡策略詳解

本篇內(nèi)容介紹了“Nginx負(fù)載均衡策略詳解”的有關(guān)知識(shí)，在實(shí)際案例的操作過程中，不少人都會(huì)遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

本文只是展示了部分nginx實(shí)現(xiàn)負(fù)載均衡時(shí)可以使用的策略模塊，另外在nginx商業(yè)版中還存在其他內(nèi)置的策略模塊。負(fù)載均衡的三方策略可以在三方模塊列表這里找到。

輪詢

nginx將所有請(qǐng)求均勻的分給集群中的每臺(tái)服務(wù)器。

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：定義一個(gè)服務(wù)集群。
proxy_pass: 將匹配的請(qǐng)求代理轉(zhuǎn)發(fā)到proxy_pass后面配置的服務(wù)上，這里因?yàn)樾枰渲秘?fù)載均衡，所以這里http://后面必須要跟上upstream定義的服務(wù)集群。

注意：upstream定義服務(wù)集群時(shí)，配置的服務(wù)地址只能是域名+端口或者ip+端口，不能帶有協(xié)議和路徑，否則nginx會(huì)報(bào)nginx: [emerg] invalid host in upstream這個(gè)錯(cuò)誤信息。

加權(quán)（weight）

upstream test {
	server 127.0.0.1:7001 weight=2;
	server 150.109.118.85:7001 weight=1;
}

前面兩次請(qǐng)求都會(huì)轉(zhuǎn)發(fā)到127.0.0.1:7001這個(gè)服務(wù)，后面一次請(qǐng)求會(huì)轉(zhuǎn)發(fā)到150.109.118.85:7001這個(gè)服務(wù)，再后面兩次轉(zhuǎn)發(fā)到127.0.0.1:7001，。。。

最少連接數(shù)

文件位置：src/http/modules/ngx_http_upstream_least_conn_module.c

nginx請(qǐng)求分配給active_connection/weight最小的服務(wù)器。

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

根據(jù)用戶的ip，計(jì)算出一個(gè)hash值，如果負(fù)載均衡緩存中有這個(gè)hash對(duì)應(yīng)的服務(wù)器，那就直接轉(zhuǎn)發(fā)到對(duì)應(yīng)的服務(wù)器上。

upstream test {
  	ip_hash;
	server 127.0.0.1:7001;
	server 150.109.118.85:7001;
}

nginx使用ip_hash策略后，只要用戶電腦的ip不變化，就會(huì)始終請(qǐng)求同一臺(tái)業(yè)務(wù)服務(wù)。

應(yīng)用場(chǎng)景：在實(shí)現(xiàn)文件上傳功能時(shí)，要實(shí)現(xiàn)一個(gè)大文件上傳，往往會(huì)將這個(gè)大文件分成多個(gè)片段，然后上傳到服務(wù)器，如果使用前面給的策略，就會(huì)出現(xiàn)同一個(gè)文件的分片被上傳到不同服務(wù)器，導(dǎo)致文件合并失敗，不能達(dá)到預(yù)期效果。nginx使用ip_hash策略后，客戶端只要上傳了當(dāng)前文件的一個(gè)片段，后續(xù)文件片段上傳的時(shí)候，nginx通過計(jì)算ip的hash，自動(dòng)把請(qǐng)求轉(zhuǎn)發(fā)到hash對(duì)應(yīng)的服務(wù)器。

hash

文件位置：src/http/modules/ngx_http_upstream_hash_module.c

可以進(jìn)行hash計(jì)算的有remote_addr（客戶端ip）（從測(cè)試結(jié)果上面看感覺可以直接替換掉ip_hash）、request_uri(請(qǐng)求uri)、args（請(qǐng)求參數(shù)），下面主要以request_uri的使用作為展示，其他兩個(gè)使用都類似。

根據(jù)請(qǐng)求的uri計(jì)算出一個(gè)hash值，然后將該請(qǐng)求轉(zhuǎn)發(fā)到一臺(tái)服務(wù)器上面，后續(xù)請(qǐng)求通過hash計(jì)算后，如果有相同的hash，那么就會(huì)將該請(qǐng)求轉(zhuǎn)發(fā)到該hash對(duì)應(yīng)的服務(wù)器。

如果集群中某臺(tái)服務(wù)器宕機(jī)之后會(huì)出現(xiàn)什么情況：假設(shè)r1命中a服務(wù)器；r2命中b服務(wù)器。當(dāng)a服務(wù)器宕機(jī)，之前通過r1計(jì)算出來的hash與a服務(wù)器的對(duì)應(yīng)情況會(huì)失效，r1將重新分配給b服務(wù)器。后續(xù)a服務(wù)器恢復(fù)正常后，r1還是會(huì)分配給b服務(wù)器。

upstream test {
  	hash $request_uri;
	server 127.0.0.1:7001;
	server 150.109.118.85:7001;
}

應(yīng)用場(chǎng)景：所有請(qǐng)求相同的文件資源的請(qǐng)求都會(huì)被轉(zhuǎn)發(fā)到同一個(gè)服務(wù)器，資源更容易命中緩存，減少寬帶和資源下載時(shí)間。

consistent_hash

consistent_hash（一致性hash）這個(gè)模塊使用方式和nginx內(nèi)置的hash模塊幾乎相同。能夠使用consistent_hash進(jìn)行計(jì)算的內(nèi)容和前面提到的nginx內(nèi)置的hash模塊一樣，有remote_addr、request_uri、args。這是一個(gè)三方模塊，可以在ngx_http_consistent_hash這里下載。

upstream test {
	consistent_hash $request_uri;
	server 127.0.0.1:7001;
	server 150.109.118.85:7001;
}

fair

響應(yīng)時(shí)間短的服務(wù)優(yōu)先分配請(qǐng)求。這個(gè)是三方模塊，可以在 nginx_ups tream_fair這里下載模塊。這個(gè)模塊上次更新是8年前，可能需要考慮下是否需要使用這個(gè)。

upstream test {
	fair;
	server 127.0.0.1:7001;
	server 150.109.118.85:7001;
}

測(cè)試中得出效果和輪詢默認(rèn)情況效果一樣，暫時(shí)沒有找到問題在哪。。。

負(fù)載均衡相關(guān)參數(shù)

down

標(biāo)識(shí)down的服務(wù)器暫時(shí)不支持資源請(qǐng)求。

upstream test {
	server 127.0.0.1:7001 down;
	server 150.109.118.85:7001;
}

上面負(fù)載均衡的例子中，因?yàn)?code>127.0.0.1:7001標(biāo)識(shí)為down，所以不會(huì)有請(qǐng)求轉(zhuǎn)發(fā)到這個(gè)服務(wù)，所有的請(qǐng)求都會(huì)轉(zhuǎn)發(fā)到150.109.118.85:7001這個(gè)服務(wù)。

weight

集群中服務(wù)的權(quán)重值，默認(rèn)是1。在只有weight這一個(gè)影響條件下，且集群中服務(wù)都正常，nginx會(huì)將更多的請(qǐng)求轉(zhuǎn)發(fā)到weight更大的服務(wù)。

upstream test {
	server 127.0.0.1:7001 weight=2;
	server 150.109.118.85:7001 weight=1;
}

這個(gè)集群中127服務(wù)和150服務(wù)各處理的請(qǐng)求比例為2:1。

max_fails

允許服務(wù)處理請(qǐng)求時(shí)服務(wù)出錯(cuò)的次數(shù)，默認(rèn)為1。當(dāng)服務(wù)處理請(qǐng)求發(fā)生錯(cuò)誤的次數(shù)超過max_fails時(shí)，后面的請(qǐng)求暫時(shí)不會(huì)轉(zhuǎn)發(fā)到這臺(tái)發(fā)生錯(cuò)誤的服務(wù)。

upstream test {
	server 127.0.0.1:7001 max_fail=1;
	server 150.109.118.85:7001;
}

fail_timeout

當(dāng)服務(wù)處理請(qǐng)求發(fā)生錯(cuò)誤的次數(shù)超過max_fails以后，nginx會(huì)暫時(shí)禁止將請(qǐng)求轉(zhuǎn)發(fā)到這個(gè)服務(wù)。當(dāng)過去fail_timeout設(shè)置的時(shí)間以后，nginx會(huì)嘗試將請(qǐng)求轉(zhuǎn)發(fā)到剛才被禁止的服務(wù)，如果服務(wù)正常，那么后續(xù)的請(qǐng)求可以繼續(xù)轉(zhuǎn)發(fā)到這臺(tái)服務(wù)，如果服務(wù)錯(cuò)誤，那么繼續(xù)等待fail_timeout時(shí)間后再來檢測(cè)。fail_timeout默認(rèn)時(shí)間是10s。

upstream test {
	server 127.0.0.1:7001 max_fail=1 fail_timeout=10s;
	server 150.109.118.85:7001;
}

backup

備用服務(wù)器，當(dāng)所有非backup服務(wù)發(fā)生錯(cuò)誤被停用或者設(shè)置為down時(shí)，nginx會(huì)啟用標(biāo)識(shí)為backup的服務(wù)。

upstream test {
	server 127.0.0.1:7001 backup;
	server 150.109.118.85:7001;
}

max_conns

這個(gè)功能存在于nginx商業(yè)版。同一服務(wù)同時(shí)處理請(qǐng)求的個(gè)數(shù)。防止服務(wù)因處理請(qǐng)求過多，服務(wù)器性能不足，發(fā)生宕機(jī)的情況。

upstream test {
	server 127.0.0.1:7001 max_conns=10000;
	server 150.109.118.85:7001;
}

slow_start

這個(gè)功能存在于nginx商業(yè)版。當(dāng)集群中錯(cuò)誤服務(wù)等待fail_timeout時(shí)間后，nginx檢測(cè)到這個(gè)服務(wù)能夠正常使用后，再等待slow_start時(shí)間后，才正式使用這個(gè)服務(wù)。

upstream test {
	server 127.0.0.1:7001 slow_start=30s;
	server 150.109.118.85:7001;
}

“Nginx負(fù)載均衡策略詳解”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！