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

這篇文章主要講解了“nginx中使用了哪些負載均衡算法”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(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ù)前方路況進行判別走哪個出口。判別的方法就可以理解為負載均衡算法?！?/p>

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

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

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

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

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

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

負載均衡的種類

DNS

(Domain Name System 域名系統(tǒng)  )它作為將域名和IP地址相互映射的一個分布式數(shù)據(jù)庫，能夠使人更方便地訪問互聯(lián)網(wǎng)。DNS使用TCP和UDP端口53。當(dāng)前，對于每一級域名長度的限制是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)過了良好嚴(yán)格的測試，經(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)存低性能高。

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

• nginx支持高并發(fā)，每個worker子進程是獨立平等的，當(dāng)有客戶端請求時，worker進程公平競爭，搶到的worker進程會把請求提交給后端服務(wù)器，當(dāng)后端服務(wù)器沒有及時響應(yīng)時，此worker進程會繼續(xù)接收下一個request,當(dāng)上一個請求有響應(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)各種各樣的問題，比如：當(dāng)有一臺服務(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)將請求分配給當(dāng)前負載最低的服務(wù)器，這里的負載根據(jù)不同請求類型和業(yè)務(wù)處理場景，可以用不同的指標(biāo)來衡量。比如以下幾個場景，

• 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)壓力的指標(biāo)。如果CPU是密集型，可以以CPU負載來衡量系統(tǒng)的壓力;如果是IO密集型，則可以以IO負載來衡量系統(tǒng)壓力。

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

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

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

負載最低優(yōu)先的算法基板上能夠很完美解決了輪訓(xùn)算法的缺點，也因為采用負載最低優(yōu)先算法后，負載均衡系統(tǒng)需要感知服務(wù)器當(dāng)前運行狀態(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)時間這個標(biāo)準(zhǔn)，在外部進行感應(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)?目前是沒有標(biāo)準(zhǔn)的周期，都是需要具體業(yè)務(wù)場景進行決策，是不是感覺到了其復(fù)雜性，尤其是線上系統(tǒng)需要不斷的調(diào)試，然后找出相對合適的標(biāo)準(zhǔn)。

Hash類

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

• 源地址Hash：將來源于同一個IP地址的請求分配給同一個服務(wù)器進行處理，適合于存在事務(wù)、會話的業(yè)務(wù)。例如：當(dāng)我們通過瀏覽器登錄網(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值將請求分到不同的機器中，當(dāng)后臺服務(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中使用了哪些負載均衡算法這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！