? ? ? ? 大家好扮叨，我是IT修真院北京分院第31期的學(xué)員直焙，一枚正直純潔善良的JAVA程序員袒啼。今天給大家分享一下锉试，修真院官網(wǎng)JAVA任務(wù)6的深度思考——nginx如何實現(xiàn)負載均衡.

1.背景介紹

什么是NGINX

Nginx (engine x) 是一個高性能的HTTP和反向代理服務(wù)器，也是一個IMAP/POP3/SMTP服務(wù)器揍移。Nginx是由伊戈爾·賽索耶夫為俄羅斯訪問量第二的Rambler.ru站點（俄文：Рамблер）開發(fā)的次和，第一個公開版本0.1.0發(fā)布于2004年10月4日。其將源代碼以類BSD許可證的形式發(fā)布羊精，因它的穩(wěn)定性斯够、豐富的功能集囚玫、示例配置文件和低系統(tǒng)資源的消耗而聞名喧锦。

2011年6月1日，nginx 1.0.4發(fā)布抓督。Nginx是一款輕量級的Web 服務(wù)器/反向代理服務(wù)器及電子郵件（IMAP/POP3）代理服務(wù)器燃少，并在一個BSD-like 協(xié)議下發(fā)行。其特點是占有內(nèi)存少铃在，并發(fā)能力強阵具，事實上nginx的并發(fā)能力確實在同類型的網(wǎng)頁服務(wù)器中表現(xiàn)較好，中國大陸使用nginx網(wǎng)站用戶有：百度定铜、京東阳液、新浪、網(wǎng)易揣炕、騰訊帘皿、淘寶等

負載均衡的目的

負載均衡的目的是為了解決單個節(jié)點壓力過大，造成Web服務(wù)響應(yīng)過慢畸陡，嚴重的情況下導(dǎo)致服務(wù)癱瘓鹰溜，無法正常提供服務(wù)。春節(jié)期間在12306網(wǎng)站上買過火車票的朋友應(yīng)該深有體會丁恭，有時查詢一張火車票都會很慢曹动，甚至整個網(wǎng)頁都卡住不動了。通常一個訪問量非常大的Web網(wǎng)站（比如：淘寶牲览、京東墓陈、12306等），由于一個Web服務(wù)同時能處理的用戶并發(fā)請求的數(shù)量有限第献，同時還有機器故障的情況贡必，所以一個Web站點通常會在N臺機器上各部署一套同樣的程序。當某一個服務(wù)掛掉的時候痊硕，還有第二個赊级、第三個、第N個服務(wù)岔绸。理逊。橡伞。繼續(xù)為用戶提供服務(wù)，給用戶的感覺晋被，你的服務(wù)還在正常的運行兑徘！

在這些提供同樣服務(wù)的機器當中，在硬件配置方面也各不一樣羡洛，這樣就會存在部份機器性能非常好挂脑，能快速計算并響應(yīng)用戶的請求，另外一部份機器可能配置差點欲侮，響應(yīng)用戶的請求的時間會長一些崭闲。這就需要我們思考一個問題？如果有一個服務(wù)正在同時處理1000個用戶的請求威蕉，這個服務(wù)的上限可能最多能同時處理1000個用戶的請求刁俭，這時它已經(jīng)很忙了，如果此時又有一個新請求過來韧涨，我們?nèi)匀话堰@個請求分配給這臺機器牍戚，這時候這個請求就只能在干等著，等這個服務(wù)處理完那些請求后虑粥，再繼續(xù)處理它如孝。

這樣在瀏覽器中的反應(yīng)就像12306我們在春節(jié)買票一樣，卡在那不動了娩贷，讓用戶眼巴巴的干著急第晰。而能提供同樣服務(wù)的其它機器，這時確很空閑育勺。這樣不僅是對服務(wù)器資源的浪費但荤，也充分發(fā)揮不出弄多臺服務(wù)器裝同一個服務(wù)的最高價值。我們通常稱對某一臺機器的訪問量稱為負載量涧至，如何將一個用戶的請求腹躁，合理的分配到一臺能快速響應(yīng)用戶請求的服務(wù)器上，我們就需要用到一些負載策略南蓬。

負載均衡纺非，將用戶的所有HTTP請求均衡的分配到每一臺機器上，充分發(fā)揮所有機器的性能赘方，提高服務(wù)的質(zhì)量和用戶體驗烧颖。負載均衡可以通過負載均衡網(wǎng)絡(luò)硬件設(shè)備和Web服務(wù)器軟件來實現(xiàn)，前者設(shè)備成本較高窄陡，小公司通常負擔不起炕淮，所以后者一般是我們的首選。實現(xiàn)負載均衡常用的Web服務(wù)器軟件有Nginx跳夭、LVS涂圆、Apache等们镜，本文主要介紹Nginx的如何實現(xiàn)負載均衡.

2.知識剖析

NGINX的UPSTREAM模塊

Nginx負載均衡是通過upstream模塊來實現(xiàn)的.upstream模塊，使nginx跨越單機的限制润歉，完成網(wǎng)絡(luò)數(shù)據(jù)的接收模狭、處理和轉(zhuǎn)發(fā)。

數(shù)據(jù)轉(zhuǎn)發(fā)功能踩衩，為nginx提供了跨越單機的橫向處理能力嚼鹉，使nginx擺脫只能為終端節(jié)點提供單一功能的限制，而使它具備了網(wǎng)路應(yīng)用級別的拆分驱富、封裝和整合的戰(zhàn)略功能锚赤。

從本質(zhì)上說，upstream屬于handler萌朱，只是他不產(chǎn)生自己的內(nèi)容宴树，而是通過請求后端服務(wù)器得到內(nèi)容策菜，所以才稱為upstream（上游）晶疼。請求并取得響應(yīng)內(nèi)容的整個過程已經(jīng)被封裝到nginx內(nèi)部，所以upstream模塊只需要開發(fā)若干回調(diào)函數(shù)又憨，完成構(gòu)造請求和解析響應(yīng)等具體的工作翠霍。

NGINX負載均衡模塊

負載均衡模塊用于從”upstream”指令定義的后端主機列表中選取一臺主機。nginx先使用負載均衡模塊找到一臺主機蠢莺，再使用upstream模塊實現(xiàn)與這臺主機的交互寒匙。

負載均衡模塊的配置區(qū)集中在upstream{}塊中。負載均衡模塊的回調(diào)函數(shù)體系是以init_upstream為起點躏将，經(jīng)歷init_peer锄弱，最終到達peer.get和peer.free。其中init_peer負責建立每個請求使用的server列表祸憋，peer.get負責從server列表中選擇某個server（一般是不重復(fù)選擇）会宪，而peer.free負責server釋放前的資源釋放工作。

NGINX的負載均衡策略

一,內(nèi)置負載策略:

輪循（默認）:Nginx根據(jù)請求次數(shù)蚯窥，將每個請求均勻分配到每臺服務(wù)器

最少連接:將請求分配給連接數(shù)最少的服務(wù)器掸鹅。Nginx會統(tǒng)計哪些服務(wù)器的連接數(shù)最少。

IP Hash :綁定處理請求的服務(wù)器拦赠。第一次請求時巍沙，根據(jù)該客戶端的IP算出一個HASH值，將請求分配到集群中的某一臺服務(wù)器上荷鼠。后面該客戶端的所有請求句携，都將通過HASH算法，找到之前處理這臺客戶端請求的服務(wù)器允乐，然后將請求交給它來處理矮嫉。

二,第三方負載策略

1>fair:

根據(jù)服務(wù)器的響應(yīng)時間來分配請求牡辽，響應(yīng)時間短的優(yōu)先分配，即負載壓力小的優(yōu)先會分配敞临。 由于fair模塊是第三方提供的态辛，所以在編譯nginx源碼的時候，需要將fair添加到nginx模塊中挺尿。

2>url_hash

按請求url的hash結(jié)果來分配請求奏黑，使每個url定向到同一個后端服務(wù)器，服務(wù)器做緩存時比較有效编矾。 1.7.2版本以后熟史，url_hash模塊已經(jīng)集成到了nginx源碼當中，不需要單獨安裝窄俏。之前的版本仍需要單獨安裝.

NGINX加權(quán)輪詢算法

Nginx的加權(quán)輪詢算法將保持選擇的平滑性蹂匹，即盡可能均勻的分攤節(jié)點，節(jié)點分配不再是連續(xù)的凹蜈。

1限寞、概念解釋，每個節(jié)點有三個權(quán)重變量仰坦，分別是： (1) weight: 約定權(quán)重履植，即在配置文件或初始化時約定好的每個節(jié)點的權(quán)重。 (2) effectiveWeight: 有效權(quán)重悄晃，初始化為weight玫霎。 在通訊過程中發(fā)現(xiàn)節(jié)點異常，則-1妈橄； 之后再次選取本節(jié)點庶近，調(diào)用成功一次則+1，直達恢復(fù)到weight眷蚓； 此變量的作用主要是節(jié)點異常鼻种，降低其權(quán)重。 (3) currentWeight: 節(jié)點當前權(quán)重溪椎，初始化為0普舆。

2、算法邏輯: (1) 輪詢所有節(jié)點校读，計算當前狀態(tài)下所有節(jié)點的effectiveWeight之和totalWeight沼侣； (2) currentWeight = currentWeight + effectiveWeight; 選出所有節(jié)點中currentWeight中最大的一個節(jié)點作為選中節(jié)點； (3) 選中節(jié)點的currentWeight = currentWeight - totalWeight歉秫； 基于以上算法蛾洛，我們看一個例子： 這時有三個節(jié)點{a, b, c}，權(quán)重分別是{a=4, b=2, c=1}，共7次請求轧膘，初始currentWeight值為{0, 0, 0}钞螟，每次分配后的結(jié)果如下：

3.編碼實戰(zhàn)

4.常見問題

一,壓力過大

壓力過大的例子:有一次，某技術(shù)哥為某金融機構(gòu)部署負載均衡谎碍。在沒部署之前鳞滨，調(diào)試沒有任何問題，也通過了壓力測試蟆淀，而且能達到3000/秒的用戶數(shù)拯啦。但是就在技術(shù)哥上了負載產(chǎn)品后，一開始還能達到 4000/秒左右熔任，轉(zhuǎn)眼卻如洪水傾瀉褒链，用戶數(shù)急速降低，甚至還不如沒上負載前疑苔。 “本來我們網(wǎng)絡(luò)沒有這么慢甫匹，現(xiàn)在加了負載均衡卻變慢了，是不是你們負載產(chǎn)品有問題啊?”用戶提出了尖銳的質(zhì) 疑惦费。經(jīng)過仔細觀察發(fā)現(xiàn)：壓力下兵迅，負載工作很正常，CPU也很低趁餐。但沒上負載前喷兼，后臺數(shù)據(jù)庫的CPU工作在85%左 右，加了負載均衡之后后雷，數(shù)據(jù)庫反而瞬間達到了百分之九十多，然后就居高不下了…… 問題原因究竟在哪兒?

細究之下發(fā)現(xiàn)吠各，原來這個機構(gòu)的數(shù)據(jù)庫平臺在設(shè)計之初臀突，沒有考慮到以后需要在負載的情況下應(yīng)用，現(xiàn)在經(jīng)過負載贾漏，給數(shù)據(jù)庫的壓力增加了候学，數(shù)據(jù)庫中某個表查詢過慢，反而導(dǎo)致了整個數(shù)據(jù)庫查詢效率降低纵散，進而影響了整個系統(tǒng)梳码。所以，綜上案例可以發(fā)現(xiàn)伍掀，負載設(shè)備和客戶的應(yīng)用業(yè)務(wù)是息息相關(guān)的掰茶，要想成功的部署負載均衡，并使其發(fā)揮預(yù)期的效果蜜笤，除了要了解客戶需求濒蒋，更要應(yīng)地制宜，知己知彼才能讓負載均衡產(chǎn)品發(fā)揮出它該有的作用。

5.參考文獻

http://network.51cto.com/art/201507/485289.htm

https://blog.csdn.net/xyang81/article/details/51702900

https://blog.csdn.net/u014513883/article/details/48550709

http://tengine.taobao.org/book/chapter_05.html

6.更多討論

鳴謝

感謝觀看,如有出錯,懇請指正

今天的分享就到這里啦沪伙，歡迎大家點贊瓮顽、轉(zhuǎn)發(fā)、留言围橡、拍磚~

????????技能樹.IT修真院

????????“我們相信人人都可以成為一個工程師暖混，現(xiàn)在開始，找個師兄翁授，帶你入門儒恋，掌控自己學(xué)習(xí)的節(jié)奏，學(xué)習(xí)的路上不再迷们”诫尽。

????????這里是技能樹.IT修真院，成千上萬的師兄在這里找到了自己的學(xué)習(xí)路線炬守，學(xué)習(xí)透明化牧嫉，成長可見化，師兄1對1免費指導(dǎo)减途『ㄔ澹快來與我一起學(xué)習(xí)吧~

我的邀請碼：17742750，或者你可以直接點擊此鏈接：http://www.jnshu.com/login/1/17742750

來源：簡書

著作權(quán)歸作者所有鳍置。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)辽剧，非商業(yè)轉(zhuǎn)載請注明出處。