共計 6103 個字符，預(yù)計需要花費 16 分鐘才能閱讀完成。

這篇文章主要講解了“nginx 中使用了哪些負載均衡算法”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學(xué)習(xí)“nginx 中使用了哪些負載均衡算法”吧！

什么是負載均衡?

負載均衡，英文名稱為 Load  Balance，其含義就是指將負載 (工作任務(wù)) 進行平衡、分攤到多個操作單元上進行運行，例如 FTP 服務(wù)器、Web 服務(wù)器、企業(yè)核心應(yīng)用服務(wù)器和其它主要任務(wù)服務(wù)器等，從而協(xié)同完成工作任務(wù)。

負載均衡通常有兩種目的：均攤壓力和提供冗余(也可以理解為備份)。

生活案列

上面還看不懂的話，我們繼續(xù)用生活案列來說：

高速路出口處，如果只有一個出口時，突然有一天出現(xiàn)大量車輛 (假設(shè)大家都沒有辦理 ETC) 這個高速出口下高速，  比如有幾百兩這會都要下高速，但是下高速要交過路費，每輛車至少也要耽擱幾分鐘，幾百輛!!! 意味著后面的可能要等幾個小時，如果有多個出口呢? 那就沒必要等那么久了。

如果在增加一個出口，這時候就是兩個出口可以均攤車輛下高速，還得分收費員快慢，車輛 3 看到車 1 那邊要快點，然后就跟上車 1。

如果再增加 n 個就可以想象效果了。但是太多了，貌似也會造成資源浪費，很多出口一天都沒有幾輛車出入，如果搞得太多豈不浪費，所以我們一般看到大多數(shù)都是兩個，可以理解備用急用。

「我們就把司機理解為負載均衡器，可以根據(jù)前方路況進行判別走哪個出口。判別的方法就可以理解為負載均衡算法。」

用我們技術(shù)領(lǐng)域的術(shù)語叫做冗余。收費員的速度我就可以理解為我們系統(tǒng)某個服務(wù)的性能。

技術(shù)領(lǐng)域

下面用一張圖來描述我們技術(shù)領(lǐng)域的負載均衡：

結(jié)合生活中的場景和技術(shù)領(lǐng)域的場景一起理解更酸爽。

注意：集群指的是我們同一個 App 應(yīng)用服務(wù)的部署多個節(jié)點，集群的主要目的就是為了分擔壓力的。負載均衡器 (系統(tǒng)) 就可以理解為指揮員。來一個請求，指揮員把這個請求根據(jù)一定方法交給集群中的某個服務(wù)。指揮員就可以按照各種方式進行分配請求到集群中的某個服務(wù)。隨機給、排隊給、誰反應(yīng)快給誰等方法，也就是形成了負載均衡算法。

以上比喻僅僅是個人理解。

負載均衡的種類

DNS

(Domain Name System 域名系統(tǒng)  )它作為將域名和 IP 地址相互映射的一個分布式數(shù)據(jù)庫，能夠使人更方便地訪問互聯(lián)網(wǎng)。DNS 使用 TCP 和 UDP 端口 53。當前，對于每一級域名長度的限制是 63 個字符，域名總長度則不能超過 253 個字符。DNS 是最簡單也是最常見的負載均衡方式，一般用來實現(xiàn)“地理級別”的負載均衡，比如說：北方人訪問北京的機房，南方人訪問廣州的機房，西方人訪問成都的機房。DNS 負載均衡的本質(zhì)是 DNS 解析同一個域名可以返回不同的 IP 地址。比如說：https://www.sina.com.cn/ 在北方的用戶使用時會解析成 10.210.1.12(北京機房)返回，南方的用戶使用時會解析成 14.213.164.27 返回(廣州機房)。

DNS 簡單示意圖

優(yōu)點

配置簡單，無成本費用

將負載均衡的工作交給了 DNS 服務(wù)器，省去了管理的麻煩。

缺點

記錄的添加與修改是需要一定時間才能夠生效的(因為 DNS 緩存了 A 記錄)。一旦有一臺服務(wù)器壞了需要下線，即使修改了 A 記錄，要使其生效也需要較長的時間，這段時間，DNS 仍然會將域名解析到已下線的服務(wù)器上，最終導(dǎo)致用戶訪問失敗。

不能按需分配負載，DNS 并不知道各服務(wù)器的真實負載情況，所以負載效果不是很好

實際的情況：在實際的項目部署，我們一般會將部分服務(wù)器使用 DNS 解析，利用域名解析作為第一級負載均衡. 再在服務(wù)器中使用 nginx 負載均衡作為第二級負載均衡。

硬件負載均衡

硬件負載均衡是通過單獨的設(shè)備來實現(xiàn)負載均衡的功能，這類設(shè)備和路由器交換機有那么一些類似，更或者可以理解為一個用于負載均衡的基礎(chǔ)網(wǎng)絡(luò)設(shè)備。目前業(yè)界主要有兩款硬件負載均衡：F5 和 A10。這類設(shè)備性能好，功能強大，但是價格可以用昂貴來形容，一般只有銀行，國企等大型有錢的企業(yè)開會考慮使用此類設(shè)備，本人也只是在銀行里見識過 F5。至于 A10 沒接觸過就不撤了。

優(yōu)點

功能強大：全面支持各層級的負載均衡，支持各種負載均衡算法，支持全局負載均衡。

性能好：一般軟件負載均衡能支撐 10w+ 并發(fā)已經(jīng)很不錯了，但是硬件的負載均衡卻可以支持 100w+ 以上的并發(fā)。

高穩(wěn)定性：因為是商業(yè)品，所以經(jīng)過了良好嚴格的測試，經(jīng)過大規(guī)模的使用，所以穩(wěn)定非常高。

安全性高：硬件負載均衡設(shè)備除了能處理負載均衡以外，還具有防火墻、防 DDOS 攻擊等效果。

缺點

價格昂貴：我記得之前銀行購買 F5 花了上百萬，據(jù)說還有更貴的，所以價格可想而知。

擴展性不好：硬件設(shè)備可以根據(jù)業(yè)務(wù)進行配置，但無法進行擴展和定制化。

軟件負載均衡

軟件負載均衡是通過負載均衡軟件來實現(xiàn)負載均衡功能的。常見的負載均衡軟件有 LVS 和 Nginx。其中 LVS 是 Linux 內(nèi)核的四層負載均衡，四層和七層的區(qū)別在于他們協(xié)議和靈活性的不同。Nginx 是 7 層負載均衡，支持 HTTP，E-mail 協(xié)議，而 LVS 是四層負載均衡，所以和協(xié)議無關(guān)，基本上所有應(yīng)用都可以做到，比如說：聊天、數(shù)據(jù)庫等。

以下是 Nginx 的負載均衡簡單示意圖：

優(yōu)點

nginx 由 C 編寫，同樣的 web 服務(wù)器，占用的資源和內(nèi)存低性能高。

當啟動 nginx 服務(wù)器，會生成一個 master 進程，master 進程會 fork 出多個 worker 進程，由 worker 線程處理客戶端的請求。

nginx 支持高并發(fā)，每個 worker 子進程是獨立平等的，當有客戶端請求時，worker 進程公平競爭，搶到的 worker 進程會把請求提交給后端服務(wù)器，當后端服務(wù)器沒有及時響應(yīng)時，此 worker 進程會繼續(xù)接收下一個 request, 當上一個請求有響應(yīng)后會觸發(fā)事件，此 worker 進程繼續(xù)之前的執(zhí)行，知道響應(yīng)結(jié)束。一個 request 不會被兩個 worker 進程執(zhí)行。

nginx 支持反向代理(用戶有感知的訪問叫正向代理如訪問 youtube，用戶無感知訪問叫反向代理如負載均衡)，支持 7 層負載均衡(拓展負載均衡的好處)。

nginx 是異步非阻塞型處理請求(第三點印證)，采用的 epollandqueue 模式，apache 是阻塞型處理請求。

nginx 處理靜態(tài)文件速度快(原因：

nginx 高度模塊化，配置簡單。

nginx 是單進程多線程)。

缺點

對比 apache 不穩(wěn)定，由于是單進程多線程，進程死掉會影響很多用戶。

負載均衡有什么用?

「流量分發(fā)」負載均衡能對多臺主機流量進行分發(fā)，提高用戶系統(tǒng)的業(yè)務(wù)處理能力，提升服務(wù)可用性

「會話保持」在會話周期內(nèi)，會話保持可使來自同一 IP 或網(wǎng)段的請求被分發(fā)到同一臺后端服務(wù)器上。

「健康檢查」支持自定義健康檢查方式和頻率，可定時檢查后端主機運行狀態(tài)，提供故障轉(zhuǎn)移，實現(xiàn)高可用;

「負載均衡」解決并發(fā)壓力，提高應(yīng)用處理性能(增加吞吐量，加強網(wǎng)絡(luò)處理能力);

提高擴展性通過添加或減少服務(wù)器數(shù)量，提供網(wǎng)站伸縮性(擴展性);

提高安全性安全防護，在負載均衡器上做一些過濾，黑白名單、防盜鏈等處理;

常用負載均衡算法

輪訓(xùn)

負載均衡系統(tǒng)接收到請求后，按照一定順序?qū)⒄埱蠓职l(fā)給服務(wù)器上。輪訓(xùn)是一種簡單的負載均衡算法策略，不會去關(guān)注服務(wù)器狀態(tài)。

優(yōu)點：如果服務(wù)器都是正常的，那么輪訓(xùn)是最理想的，因為它會使得每個服務(wù)都得到相等量的請求，可以用 雨露均沾 來形容。

缺點：上面的有點是理想狀態(tài)的，但是現(xiàn)實往往不是那樣的，現(xiàn)實還是很骨感滴，線上系統(tǒng)往往出現(xiàn)各種各樣的問題，比如：當有一臺服務(wù)器掛了，輪訓(xùn)算法不會管服務(wù)器狀態(tài)，就是會導(dǎo)致大量的請求到一臺已經(jīng)掛掉的服務(wù)器上，從而導(dǎo)致系統(tǒng)不可用，進而造成用戶流失。另外一種常見的問題就是有的服務(wù)器響應(yīng)快，有的響應(yīng)慢(比如 32 核的服務(wù)器和 16 核的服務(wù)器)，輪訓(xùn)算法也不關(guān)注相應(yīng)快慢，所以會導(dǎo)致很多服務(wù)請求響應(yīng)時間慢，簡單的導(dǎo)致用戶體驗不好，由于響應(yīng)時間慢甚至可能拖垮其他系統(tǒng)。

加權(quán)輪訓(xùn)

負載均衡系統(tǒng)根據(jù)服務(wù)器權(quán)重進行請求任務(wù)分派到對應(yīng)的服務(wù)器上，這里的權(quán)重一般是根據(jù)系統(tǒng)硬件配置進行靜態(tài)配置的，采用動態(tài)的方式計算會更加適合業(yè)務(wù)，但是復(fù)雜度相比簡單的輪訓(xùn)就高很多。

加權(quán)輪訓(xùn)是輪訓(xùn)的一種特殊方式，主要目的是解決服務(wù)器處理能力的差異問題，比如：集群中有的服務(wù)器是 32 核，有的老系統(tǒng)卻是 16 核，那么理論上我們可以對其進行權(quán)重配置值，即就是 32 核服務(wù)器的處理能力是 16 核的兩倍，負載均衡算法權(quán)重比例調(diào)整為 2:1，讓更多的請求分發(fā)給 32 核的服務(wù)器。

加權(quán)輪訓(xùn)解決了輪訓(xùn)算法中誤服根據(jù)服務(wù)器的配置的差異任務(wù)進行更好的分配的問題，其實還是會存在無法根據(jù)服務(wù)器的狀態(tài)差異性進行請求任務(wù)分配的問題。

負載最低優(yōu)先

負載系統(tǒng)將請求分配給當前負載最低的服務(wù)器，這里的負載根據(jù)不同請求類型和業(yè)務(wù)處理場景，可以用不同的指標來衡量。比如以下幾個場景，

LVS 這種 4 層網(wǎng)絡(luò)負載均衡設(shè)備，可以以連接數(shù)來判斷服務(wù)器的狀態(tài)，服務(wù)器連接數(shù)量越大，表明服務(wù)器壓力就越大。

Nginx 這種 7 層網(wǎng)絡(luò)負載均衡系統(tǒng)，可以以 HTTP 請求數(shù)量判斷服務(wù)器的狀態(tài)(Nginx 內(nèi)置的負載均衡算法不支持這種方式，需要自行進行擴展)。

如果我們是自己研發(fā)負載均衡系統(tǒng)，可以根據(jù)業(yè)務(wù)特點來選擇衡量系統(tǒng)壓力的指標。如果 CPU 是密集型，可以以 CPU 負載來衡量系統(tǒng)的壓力; 如果是 IO 密集型，則可以以 IO 負載來衡量系統(tǒng)壓力。

負載最低優(yōu)先算法解決了輪訓(xùn)算法中無法感知服務(wù)器狀態(tài)的問題，但是由此帶來的代價是復(fù)雜度增加很多，比如：

最少鏈接數(shù)優(yōu)先的算法要求負載系統(tǒng)統(tǒng)計每個服務(wù)器當前簡歷的鏈接，其應(yīng)用場景僅限于負載均衡接收的任何請求都會轉(zhuǎn)發(fā)給服務(wù)器進行處理，否則如果負載均衡系統(tǒng)和服務(wù)之間是固定的連接池方式，就不適合采取這種算法。LVS 可以采取這種算法進行負載均衡，而一個通過連接池的方式鏈接數(shù)據(jù)庫 Mysql 集群的負載均衡系統(tǒng)就不適合采取這種算法進行負載均衡了。

CPU 負載均衡最低優(yōu)先的算法要求負載均衡系統(tǒng)以某種方式收集每個服務(wù)器的 CPU 的具體負載情況，同時要確定是以一分鐘的負載標準，還是以 10 分鐘、15 分鐘的負載標準，不存在 1 分鐘肯定比 15 分鐘的好或差。不同業(yè)務(wù)最優(yōu)的時間間隔也是不一樣的，時間間隔太短容易造成頻繁波動，時間太長可能造成峰值來臨時響應(yīng)緩慢。

負載最低優(yōu)先的算法基板上能夠很完美解決了輪訓(xùn)算法的缺點，也因為采用負載最低優(yōu)先算法后，負載均衡系統(tǒng)需要感知服務(wù)器當前運行狀態(tài)，此時，同樣造成代價上升很多。對于開發(fā)者來說也許輪訓(xùn)算法只要簡短的代碼就可以實現(xiàn)，然而負載最低優(yōu)先算法需要大量的代碼來實現(xiàn)。

負載最低優(yōu)先看起來是解決了輪訓(xùn)中的缺點，然后由于其復(fù)雜度的提升，導(dǎo)致真正使用中比例還不如輪訓(xùn)或者輪訓(xùn)加權(quán)算法。

性能最優(yōu)

負載最低優(yōu)先算法是站在服務(wù)器的角度來進行請求分配的，而性能最優(yōu)算法是站在客戶端的角度進行分配的，優(yōu)先將請求分配給處理速度快的服務(wù)器，通過這種方式達到了最快響應(yīng)給客戶端。

性能優(yōu)先其實也負載最低優(yōu)先有點類似，都是需要感知服務(wù)器的狀態(tài)，與之不同的是性能最優(yōu)是通過響應(yīng)時間這個標準，在外部進行感應(yīng)服務(wù)器狀態(tài)而已，同樣的實現(xiàn)復(fù)雜度也很高，主要體現(xiàn)在以下方面：

負載均衡系統(tǒng)需要收集每次請求的響應(yīng)時間，如果在大量請求處理的場景下，這種收集再加上響應(yīng)時間的統(tǒng)計本身也會消耗系統(tǒng)的性能。

為了減少這種統(tǒng)計上的消耗，可以采取采樣的方式進行統(tǒng)計，即就是不用很完全的去統(tǒng)計所有服務(wù)器的所有請求時間，而是抽樣統(tǒng)計部分任務(wù)的響應(yīng)時間來估算整體請求所花的響應(yīng)時間。采樣統(tǒng)計雖然能減輕性能的消耗，但使得實現(xiàn)的復(fù)雜度增加了很多，因為要確定合適的采樣率，采樣率太低會導(dǎo)致數(shù)據(jù)的正確性，采樣率高同樣會造成性能的消耗，要找到一個合適的采樣率的復(fù)雜度也是可想而知的。

無論全部統(tǒng)計，還是采樣統(tǒng)計，都需要選擇合適的周期，是 30 秒性能最優(yōu)還是 1 分鐘最優(yōu)? 目前是沒有標準的周期，都是需要具體業(yè)務(wù)場景進行決策，是不是感覺到了其復(fù)雜性，尤其是線上系統(tǒng)需要不斷的調(diào)試，然后找出相對合適的標準。

Hash 類

負載均衡系統(tǒng)根據(jù)請求中某些關(guān)鍵字進行 hash 運算，得到的相同值得分發(fā)到同一臺服務(wù)器上去，這樣做的目的主要是為了滿足特定的業(yè)務(wù)需求，比如：

源地址 Hash：將來源于同一個 IP 地址的請求分配給同一個服務(wù)器進行處理，適合于存在事務(wù)、會話的業(yè)務(wù)。例如：當我們通過瀏覽器登錄網(wǎng)上銀行時，會生成一個會話信息，這個會話是臨時的，關(guān)閉瀏覽器后就會失效。網(wǎng)上銀行后臺無須持久會話信息，只需要在某臺服務(wù)器臨時保留這個會話就可以了，但需要保證用戶在會話存在期間，每次請求都能訪問在同一個服務(wù)器，這種業(yè)務(wù)場景就是通過源地址 hash 來實現(xiàn)的。

ID hash：將某個 ID 表示的業(yè)務(wù)分配到同一臺服務(wù)器上進行處理，比如：userId session id。上述的網(wǎng)上銀行登錄的例子，用 session  id hash 可以實現(xiàn)同一個會話期間，用戶每次都是訪問同一臺服務(wù)器上的目的。

負載均衡算法應(yīng)用

Dubbo 中使用了哪些負載均衡算法?

Random LoadBalance(隨機算法，默認)

RoundRobin LoadBalance(權(quán)重輪訓(xùn)算法)

LeastAction LoadBalance(最少活躍調(diào)用數(shù)算法)

ConsistentHash LoadBalance(一致性 Hash 法)

類圖

nginx 中使用了哪些負載均衡算法?

「round  robin(默認)」: 輪詢方式，依次將請求分配到各個后臺服務(wù)器中，默認的負載均衡方式。適用于后臺機器性能一致的情況。掛掉的機器可以自動從服務(wù)列表中剔除。

「weight」：根據(jù)權(quán)重來分發(fā)請求到不同的機器中，指定輪詢幾率，weight 和訪問比率成正比，用于后端服務(wù)器性能不均的情況。例如：

upstream bakend { server 192.168.0.14 weight=10; server 192.168.0.15 weight=10; }

「IP_hash」：根據(jù)請求者 ip 的 hash 值將請求發(fā)送到后臺服務(wù)器中，可以保證來自同一 ip 的請求被打到固定的機器上，可以解決 session 問題。例如：

upstream bakend { ip_hash; server 192.168.0.14:88; server 192.168.0.15:80; }

「url_hash(第三方)」：根據(jù)請求的 url 的 hash 值將請求分到不同的機器中，當后臺服務(wù)器為緩存的時候效率高。

例如：在 upstream 中加入 hash 語句，server 語句中不能寫入 weight 等其他的參數(shù)，hash_method 是使用的 hash 算法。

「fair(第三方)」：根據(jù)后臺響應(yīng)時間來分發(fā)請求，響應(yīng)時間短的分發(fā)的請求多。例如：

upstream backend { server server1; server server2; fair; }

感謝各位的閱讀，以上就是“nginx 中使用了哪些負載均衡算法”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對 nginx 中使用了哪些負載均衡算法這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！