LVS實現(xiàn)負載均衡的原理與實踐是怎樣的

LVS實現(xiàn)負載均衡的原理與實踐是怎樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學(xué)習(xí)下，希望你能有所收獲。

負載均衡的原理

這是1998年一個普通的上午。

一上班，老板就把張大胖叫進了辦公室，一邊舒服地喝茶一邊發(fā)難：“大胖啊，我們公司開發(fā)的這個網(wǎng)站，現(xiàn)在怎么越來越慢了？ ”

還好張大胖也注意到了這個問題，他早有準(zhǔn)備，一臉無奈地說： “唉，我昨天檢查了一下系統(tǒng)，現(xiàn)在的訪問量已經(jīng)越來越大了，無論是CPU，還是硬盤、內(nèi)存都不堪重負了，高峰期的響應(yīng)速度越來越慢。”

頓了一下，他試探地問道：“老板，能不能買個好機器？ 把現(xiàn)在的‘老破小’服務(wù)器給替換掉。我聽說IBM的服務(wù)器挺好的，性能強勁，要不來一臺？” 

“好你個頭，你知道那機器得多貴嗎？! 我們小公司，用不起??！” 摳門的老板立刻否決。 “這……” 大胖表示黔驢技窮了。 “你去和CTO Bill 商量下， 明天給我弄個方案出來?！?/p>

老板不管過程，只要結(jié)果。

隱藏真實服務(wù)器

大胖悻悻地去找Bill。 他將老板的指示聲情并茂地做了傳達。

Bill笑了：“我最近也在思考這件事，想和你商量一下，看看能不能買幾臺便宜的服務(wù)器，把系統(tǒng)多部署幾份，橫向擴展(Scale Out)一下。 ”

橫向擴展？ 張大胖心中尋思著，如果把系統(tǒng)部署到幾個服務(wù)器上，用戶的訪問請求就可以分散到各個服務(wù)器，那單臺服務(wù)器的壓力就小得多了。

“可是，” 張大胖問道 ，“機器多了，每個機器一個IP， 用戶可能就迷糊了，到底訪問哪一個？”

“肯定不能把這些服務(wù)器暴露出去，從客戶角度看來，最好是只有一個服務(wù)器?！?Bill 說道。

張大胖眼前一亮， 突然有了主意：“有了！我們有個中間層啊，對，就是DNS，我們可以設(shè)置一下，讓我們網(wǎng)站的域名映射到多個服務(wù)器的IP，用戶面對的是我們系統(tǒng)的域名，然后我們可以采用一種輪詢的方式， 用戶1的機器做域名解析的時候，DNS返回IP1, 用戶2的機器做域名解析的時候，DNS返回IP2…… 這樣不就可以實現(xiàn)各個機器的負載相對均衡了嗎？”

Bill 思考片刻，發(fā)現(xiàn)了漏洞：“這樣做有個很要命的問題，由于DNS這個分層的系統(tǒng)中有緩存，用戶端的機器也有緩存，如果某個機器出故障，域名解析仍然會返回那個出問題機器的IP，那所有訪問該機器的用戶都會出問題， 即使我們把這個機器的IP從DNS中刪除也不行， 這就麻煩了?！?/p>

張大胖確實是沒想到這個緩存帶來的問題， 他撓撓頭：“那就不好辦了?！?/p>

偷天換日

“要不我們自己開發(fā)一個軟件實現(xiàn)負載均衡怎么樣？” Bill另辟蹊徑。

為了展示自己的想法， 他在白板上畫了一張圖， “看到中間那個藍色服務(wù)器沒有，我們可以把它稱為Load Balancer （簡稱LB）， 用戶的請求都發(fā)給他，然后它再發(fā)給各個服務(wù)器?！?/p>

張大胖仔細審視這個圖。

Load Balancer 簡稱LB ， 有兩個IP，一個對外（115.39.19.22），一個對內(nèi)(192.168.0.100)。用戶看到的是那個對外的IP。 后面的真正提供服務(wù)的服務(wù)器有三個，稱為RS1, RS2,RS3， 他們的網(wǎng)關(guān)都指向LB。

“但是怎么轉(zhuǎn)發(fā)請求呢？嗯， 用戶的請求到底是什么東西？” 張大胖迷糊了。

“你把計算機網(wǎng)絡(luò)都忘了吧？ 就是用戶發(fā)過來的數(shù)據(jù)包嘛！ 你看這個層層封裝的數(shù)據(jù)包，用戶發(fā)了一個HTTP的請求，想要訪問我們網(wǎng)站的首頁，這個HTTP請求被放到一個TCP報文中，再被放到一個IP數(shù)據(jù)報中， 最終的目的地就是我們的Load Balancer（115.39.19.22）?！?/p>

（注： 客戶發(fā)給LB的數(shù)據(jù)包， 沒有畫出數(shù)據(jù)鏈路層的幀）

“但是這個數(shù)據(jù)包一看就是發(fā)給Load Balancer的， 怎么發(fā)給后面的服務(wù)器？”

Bill 說： “可以偷天換日，比如Load Balancer想把這個數(shù)據(jù)包發(fā)給RS1（192.168.0.10）, 就可以做點手腳，把這個數(shù)據(jù)包改成這樣， 然后這個IP數(shù)據(jù)包就可以轉(zhuǎn)發(fā)給RS1去處理了?！?/p>

（LB動了手腳，把目的地IP和端口改為RS1的）

“RS1處理完了，要返回首頁的HTML，還要把HTTP報文層層封裝：” 張大胖明白怎么回事了：

（RS1處理完了，要發(fā)送結(jié)果給客戶端）

“由于LB是網(wǎng)關(guān)，它還會收到這個數(shù)據(jù)包，它就可以再次施展手段，把源地址和源端口都替換為自己的，然后發(fā)給客戶就可以了?！?/p>

(LB再次動手腳，把源地址和端口改成自己的， 讓客戶端毫無察覺)

張大胖總結(jié)了一下數(shù)據(jù)的流向： 客戶端 –> Load Balancer –> RS –> Load Balancer –> 客戶端

他興奮地說：“這招瞞天過海真是妙啊，客戶端根本就感受不到后面有好幾臺服務(wù)器在工作，它一直以為只有Load Balancer在干活?！?/p>

Bill此刻在思考Load Balancer 怎么樣才能選取后面的各個真實的服務(wù)器， 可以有很多種策略，他在白板上寫到：

輪詢： 這個最簡單，就是一個挨一個輪換。

加權(quán)輪詢： 為了應(yīng)對某些服務(wù)器性能好，可以讓他們的權(quán)重高一點，被選中的幾率大一點。

最少連接： 哪個服務(wù)器處理的連接少，就發(fā)給誰。

加權(quán)最少連接：在最少連接的基礎(chǔ)上，也加上權(quán)重 …… 還有些其他的算法和策略，以后慢慢想。

四層還是七層?

張大胖卻想到了另外一個問題： 對于用戶的一個請求來說，可能會被分成多個數(shù)據(jù)包來發(fā)送， 如果這些數(shù)據(jù)包被我們的Load Balancer發(fā)到了不同的機器上，那就完全亂套了?。?他把自己的想法告訴了Bill。

Bill說：“這個問題很好啊，我們的Load Balancer必須得維護一個表，這個表需要記錄下客戶端的數(shù)據(jù)包被我們轉(zhuǎn)發(fā)到了哪個真實的服務(wù)器上， 這樣當(dāng)下一個數(shù)據(jù)包到來時，我們就可以把它轉(zhuǎn)發(fā)到同一個服務(wù)器上去?！?/p>

“看來這個負載均衡軟件需要是面向連接的，也就是OSI網(wǎng)絡(luò)體系的第4層， 可以稱為四層負載均衡”Bill做了一個總結(jié)。

“既然有四層負載均衡，那是不是也可以搞個七層的負載均衡??？” 張大胖突發(fā)奇想。

“那是肯定的，如果我們的Load Balancer把HTTP層的報文數(shù)據(jù)取出來，根據(jù)其中的URL，瀏覽器，語言等信息，把請求分發(fā)到后面真實的服務(wù)器去，那就是七層的負載均衡了。不過我們現(xiàn)階段先實現(xiàn)一個四層的吧，七層的以后再說?！?/p>

Bill 吩咐張大胖組織人力把這個負載均衡軟件給開發(fā)出來。

張大胖不敢怠慢，由于涉及到協(xié)議的細節(jié)問題，張大胖還買了幾本書：《TCP/IP詳解》 卷一,卷二,卷三， 帶著人快速復(fù)習(xí)了C語言， 然后開始瘋狂開發(fā)。

責(zé)任分離

三個月后，Load Balancer的第一版開發(fā)出來了，這是運行在Linux上的一個軟件， 公司試用了一下，感覺還真是不錯，僅僅用幾臺便宜的服務(wù)器就可以實現(xiàn)負載均衡了。

老板看到?jīng)]花多少錢就解決了問題，非常滿意，給張大胖所在的開發(fā)組發(fā)了1000塊錢獎金，組織大家出去搓了一頓。

張大胖他們看到老板很摳門，雖略有不滿，但是想到通過這個軟件的開發(fā)，學(xué)到了很多底層的知識，尤其是TCP協(xié)議，也就忍了。

可是好景不長，張大胖發(fā)現(xiàn)這個Load Balancer存在這瓶頸：所有的流量都要通過它，它要修改客戶發(fā)來的數(shù)據(jù)包， 還要修改發(fā)給客戶的數(shù)據(jù)包。

網(wǎng)絡(luò)訪問還有個極大的特點，那就是請求報文較短而響應(yīng)報文往往包含大量的數(shù)據(jù)。這是很容易理解的，一個HTTP GET請求短得可憐，可是返回的HTML卻是極長 – 這就進一步加劇了Load Balancer修改數(shù)據(jù)包的工作。

張大胖趕緊去找Bill ，Bill說：“這確實是個問題，我們把請求和響應(yīng)分開處理吧，讓Load Balancer只處理請求，讓各個服務(wù)器把響應(yīng)直接發(fā)給客戶端，這樣瓶頸不就消除了嗎？”

“怎么分開處理？”

“首先讓所有的服務(wù)器都有同一個IP， 我們把他稱為VIP吧（如圖中115.39.19.22）?！?/p>

張大胖通過第一版Load Balancer的開發(fā)，積累了豐富的經(jīng)驗。

他問道：“你這是把每個實際服務(wù)器的loopback都綁定了那個VIP， 不過有問題啊，這么多服務(wù)器都有同樣的IP , 當(dāng)IP數(shù)據(jù)包來的時候，到底應(yīng)該由哪個服務(wù)器來處理？”

“注意，IP數(shù)據(jù)包其實是通過數(shù)據(jù)鏈路層發(fā)過來的，你看看這個圖。”

張大胖看到了客戶端的HTTP報文再次被封裝儲層TCP報文，端口號是80， 然后IP數(shù)據(jù)報中的目的地是115.39.19.22(VIP)。

圖中的問號是目的地的MAC地址， 該怎么得到呢？

對， 是使用ARP協(xié)議，把一個IP地址（115.39.19.22）給廣播出去，然后具有此IP機器就會回復(fù)自己的MAC地址。 但是現(xiàn)在有好幾臺機器都有同一個IP（115.39.19.22）， 怎么辦？

Bill 說道：“我們只讓Load Balancer 響應(yīng)這個VIP地址（115.39.19.22）的ARP請求，對于RS1,RS2,RS3, 抑制住對這個VIP地址的ARP響應(yīng)，不就可以唯一地確定Load Balancer了？ ”

原來如此！張大胖恍然大悟。

既然Load Balancer得到了這個IP數(shù)據(jù)包， 它就可以用某個策略從RS1, RS2,RS3中選取一個服務(wù)器，例如RS1（192.168.0.10），把IP數(shù)據(jù)報原封不動， 封裝成數(shù)據(jù)鏈路層的包（目的地是RS1的MAC地址），直接轉(zhuǎn)發(fā)就可以了。

RS1（192.168.0.10）這個服務(wù)器收到了數(shù)據(jù)包，拆開一看，目的地IP是115.39.19.22，是自己的IP， 那就可以處理了。

處理完了以后，RS1可以直接響應(yīng)發(fā)回給客戶端，完全不用再通過Load Balancer。因為自己的地址就是115.39.19.22。

對于客戶端來說，它看到的還是那個唯一的地址115.39.19.22， 并不知道后臺發(fā)生了什么事情。

Bill補充到：“由于Load Balancer 根本不會修改IP數(shù)據(jù)報，其中的TCP的端口號自然也不會修改，這就要求RS1, RS2,RS3上的端口號必須得和Load Balancer一致才行?！?/p>

像之前一樣，張大胖總結(jié)了一下數(shù)據(jù)的流向：

客戶端 –> Load Balancer –> RS –> 客戶端

Bill 說道：“怎么樣？ 這個辦法還可以吧？”

張大胖又想了想，這種方式似乎沒有漏洞，并且效率很高，Load Balancer只負責(zé)把用戶請求發(fā)給特定的服務(wù)器就萬事大吉了， 剩下的事由具體的服務(wù)器來處理，和它沒有關(guān)系了。

他高興地說：“不錯，我著手帶人去實現(xiàn)了?！?/p>

后記： 本文所描述的，其實就是著名開源軟件LVS的原理，上面講的兩種負載均衡的方式，就是LVS的NAT和DR。 LVS是章文嵩博士在1998年5月成立的自由軟件項目，現(xiàn)在已經(jīng)是Linux內(nèi)核的一部分。想想那時候我還在不亦樂乎地折騰個人網(wǎng)頁，學(xué)會安裝和使用Linux 沒多久 , 服務(wù)器端開發(fā)也僅限于ASP，像LVS這種負載均衡的概念壓根就沒有聽說過。 編程語言可以學(xué)，差距也能彌補，但是這種境界和眼光的差距，簡直就是巨大的鴻溝，難以跨越啊！ 讀故事筆記：關(guān)于LVS的文章也讀過幾篇，往往只是記住了概念，不能設(shè)身處地的思考為何而來，劉欣老師每每都能以人物設(shè)定的場景，讓我再次回到那個年代去思考、推演，還原當(dāng)時如何一步步的演進成后來的LVS。

本人也混跡軟件開發(fā)十幾年，多數(shù)時間都是做著行業(yè)領(lǐng)域的軟件開發(fā)，自我安慰是做著xx行業(yè)與計算機行業(yè)的交叉領(lǐng)域，實則一直未能深入計算機系統(tǒng)領(lǐng)域。行業(yè)應(yīng)用軟件開發(fā)，行業(yè)知識本身就牽扯了太多了精力，軟件開發(fā)更多選擇一種合適的架構(gòu)來完成系統(tǒng)的設(shè)計、開發(fā)和維護。如你要成為一個計算機高手，有機會還是應(yīng)當(dāng)就計算機某一個領(lǐng)域深入研究，如Linux內(nèi)核、搜索、圖形圖像、數(shù)據(jù)庫、分布式存儲，當(dāng)然還有人工智能等等。

分布式架構(gòu)實踐——負載均衡

也許當(dāng)我老了，也一樣寫代碼；不為別的，只為了愛好。

1 什么是負載均衡（Load balancing）

在網(wǎng)站創(chuàng)立初期，我們一般都使用單臺機器對臺提供集中式服務(wù)，但是隨著業(yè)務(wù)量越來越大，無論是性能上還是穩(wěn)定性上都有了更大的挑戰(zhàn)。這時候我們就會想到通過擴容的方式來提供更好的服務(wù)。我們一般會把多臺機器組成一個集群對外提供服務(wù)。然而，我們的網(wǎng)站對外提供的訪問入口都是一個的，比如 www.taobao.com。那么當(dāng)用戶在瀏覽器輸入 www.taobao.com的時候如何將用戶的請求分發(fā)到集群中不同的機器上呢，這就是負載均衡在做的事情。

當(dāng)前大多數(shù)的互聯(lián)網(wǎng)系統(tǒng)都使用了服務(wù)器集群技術(shù)，集群即將相同服務(wù)部署在多臺服務(wù)器上構(gòu)成一個集群整體對外提供服務(wù)，這些集群可以是Web應(yīng)用服務(wù)器集群，也可以是數(shù)據(jù)庫服務(wù)器集群，還可以是分布式緩存服務(wù)器集群等等。

在實際應(yīng)用中，在Web服務(wù)器集群之前總會有一臺負載均衡服務(wù)器，負載均衡設(shè)備的任務(wù)就是作為Web服務(wù)器流量的入口，挑選最合適的一臺Web服務(wù)器，將客戶端的請求轉(zhuǎn)發(fā)給它處理，實現(xiàn)客戶端到真實服務(wù)端的透明轉(zhuǎn)發(fā)。最近幾年很火的「云計算」以及分布式架構(gòu)，本質(zhì)上也是將后端服務(wù)器作為計算資源、存儲資源，由某臺管理服務(wù)器封裝成一個服務(wù)對外提供，客戶端不需要關(guān)心真正提供服務(wù)的是哪臺機器，在它看來，就好像它面對的是一臺擁有近乎無限能力的服務(wù)器，而本質(zhì)上，真正提供服務(wù)的，是后端的集群。 軟件負載解決的兩個核心問題是：選誰、轉(zhuǎn)發(fā)，其中最著名的是LVS（Linux Virtual Server）。

一個典型的互聯(lián)網(wǎng)應(yīng)用的拓撲結(jié)構(gòu)是這樣的：

2 負載均衡分類

現(xiàn)在我們知道，負載均衡就是一種計算機網(wǎng)絡(luò)技術(shù)，用來在多個計算機（計算機集群）、網(wǎng)絡(luò)連接、CPU、磁碟驅(qū)動器或其他資源中分配負載，以達到最佳化資源使用、最大化吞吐率、最小化響應(yīng)時間、同時避免過載的目的。那么，這種計算機技術(shù)的實現(xiàn)方式有多種。大致可以分為以下幾種，其中最常用的是四層和七層負載均衡：

二層負載均衡 負載均衡服務(wù)器對外依然提供一個VIP（虛IP），集群中不同的機器采用相同IP地址，但是機器的MAC地址不一樣。當(dāng)負載均衡服務(wù)器接受到請求之后，通過改寫報文的目標(biāo)MAC地址的方式將請求轉(zhuǎn)發(fā)到目標(biāo)機器實現(xiàn)負載均衡。

三層負載均衡 和二層負載均衡類似，負載均衡服務(wù)器對外依然提供一個VIP（虛IP），但是集群中不同的機器采用不同的IP地址。當(dāng)負載均衡服務(wù)器接受到請求之后，根據(jù)不同的負載均衡算法，通過IP將請求轉(zhuǎn)發(fā)至不同的真實服務(wù)器。

四層負載均衡 四層負載均衡工作在OSI模型的傳輸層，由于在傳輸層，只有TCP/UDP協(xié)議，這兩種協(xié)議中除了包含源IP、目標(biāo)IP以外，還包含源端口號及目的端口號。四層負載均衡服務(wù)器在接受到客戶端請求后，以后通過修改數(shù)據(jù)包的地址信息（IP+端口號）將流量轉(zhuǎn)發(fā)到應(yīng)用服務(wù)器。

七層負載均衡 七層負載均衡工作在OSI模型的應(yīng)用層，應(yīng)用層協(xié)議較多，常用http、radius、dns等。七層負載就可以基于這些協(xié)議來負載。這些應(yīng)用層協(xié)議中會包含很多有意義的內(nèi)容。比如同一個Web服務(wù)器的負載均衡，除了根據(jù)IP加端口進行負載外，還可根據(jù)七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。

對于一般的應(yīng)用來說，有了Nginx就夠了。Nginx可以用于七層負載均衡。但是對于一些大的網(wǎng)站，一般會采用DNS+四層負載+七層負載的方式進行多層次負載均衡。

3 常用負載均衡工具

硬件負載均衡性能優(yōu)越，功能全面，但是價格昂貴，一般適合初期或者土豪級公司長期使用。因此軟件負載均衡在互聯(lián)網(wǎng)領(lǐng)域大量使用。常用的軟件負載均衡軟件有Nginx，Lvs，HaProxy等。 Nginx/LVS/HAProxy是目前使用最廣泛的三種負載均衡軟件。

3.1 LVS

LVS（Linux Virtual Server），也就是Linux虛擬服務(wù)器, 是一個由章文嵩博士發(fā)起的自由軟件項目。使用LVS技術(shù)要達到的目標(biāo)是：通過LVS提供的負載均衡技術(shù)和Linux操作系統(tǒng)實現(xiàn)一個高性能、高可用的服務(wù)器群集，它具有良好可靠性、可擴展性和可操作性。從而以低廉的成本實現(xiàn)最優(yōu)的服務(wù)性能。 LVS主要用來做四層負載均衡。

LVS架構(gòu) LVS架設(shè)的服務(wù)器集群系統(tǒng)有三個部分組成：最前端的負載均衡層（Loader Balancer），中間的服務(wù)器群組層，用Server Array表示，最底層的數(shù)據(jù)共享存儲層，用Shared Storage表示。在用戶看來所有的應(yīng)用都是透明的，用戶只是在使用一個虛擬服務(wù)器提供的高性能服務(wù)。

LVS的體系架構(gòu).png

LVS的各個層次的詳細介紹：

Load Balancer層：位于整個集群系統(tǒng)的最前端，由一臺或者多臺負載調(diào)度器（Director Server）組成，LVS模塊就安裝在Director Server上，而Director的主要作用類似于一個路由器，它含有完成LVS功能所設(shè)定的路由表，通過這些路由表把用戶的請求分發(fā)給Server Array層的應(yīng)用服務(wù)器（Real Server）上。同時，在Director Server上還要安裝對Real Server服務(wù)的監(jiān)控模塊Ldirectord，此模塊用于監(jiān)測各個Real Server服務(wù)的健康狀況。在Real Server不可用時把它從LVS路由表中剔除，恢復(fù)時重新加入。

Server Array層：由一組實際運行應(yīng)用服務(wù)的機器組成，Real Server可以是WEB服務(wù)器、MAIL服務(wù)器、FTP服務(wù)器、DNS服務(wù)器、視頻服務(wù)器中的一個或者多個，每個Real Server之間通過高速的LAN或分布在各地的WAN相連接。在實際的應(yīng)用中，Director Server也可以同時兼任Real Server的角色。

Shared Storage層：是為所有Real Server提供共享存儲空間和內(nèi)容一致性的存儲區(qū)域，在物理上，一般有磁盤陣列設(shè)備組成，為了提供內(nèi)容的一致性，一般可以通過NFS網(wǎng)絡(luò)文件系統(tǒng)共享數(shù) 據(jù)，但是NFS在繁忙的業(yè)務(wù)系統(tǒng)中，性能并不是很好，此時可以采用集群文件系統(tǒng)，例如Red hat的GFS文件系統(tǒng)，oracle提供的OCFS2文件系統(tǒng)等。

從整個LVS結(jié)構(gòu)可以看出，Director Server是整個LVS的核心，目前，用于Director Server的操作系統(tǒng)只能是Linux和FreeBSD，linux2.6內(nèi)核不用任何設(shè)置就可以支持LVS功能，而FreeBSD作為 Director Server的應(yīng)用還不是很多，性能也不是很好。對于Real Server，幾乎可以是所有的系統(tǒng)平臺，Linux、windows、Solaris、AIX、BSD系列都能很好的支持。

3.2 Nginx

Nginx（發(fā)音同engine x）是一個網(wǎng)頁服務(wù)器，它能反向代理HTTP, HTTPS, SMTP, POP3, IMAP的協(xié)議鏈接，以及一個負載均衡器和一個HTTP緩存。 Nginx主要用來做七層負載均衡。 并發(fā)性能：官方支持每秒5萬并發(fā)，實際國內(nèi)一般到每秒2萬并發(fā)，有優(yōu)化到每秒10萬并發(fā)的。具體性能看應(yīng)用場景。

特點

模塊化設(shè)計：良好的擴展性，可以通過模塊方式進行功能擴展。 高可靠性：主控進程和worker是同步實現(xiàn)的，一個worker出現(xiàn)問題，會立刻啟動另一個worker。 內(nèi)存消耗低：一萬個長連接（keep-alive）,僅消耗2.5MB內(nèi)存。 支持熱部署：不用停止服務(wù)器，實現(xiàn)更新配置文件，更換日志文件、更新服務(wù)器程序版本。 并發(fā)能力強：官方數(shù)據(jù)每秒支持5萬并發(fā)； 功能豐富：優(yōu)秀的反向代理功能和靈活的負載均衡策略 Nginx的基本工作模式

Nginx的基本工作模式.jpg

一個master進程，生成一個或者多個worker進程。但是這里master是使用root身份啟動的，因為nginx要工作在80端口。而只有管理員才有權(quán)限啟動小于低于1023的端口。master主要是負責(zé)的作用只是啟動worker，加載配置文件，負責(zé)系統(tǒng)的平滑升級。其它的工作是交給worker。那么當(dāng)worker被啟動之后，也只是負責(zé)一些web最簡單的工作，而其他的工作都是由worker中調(diào)用的模塊來實現(xiàn)的。 模塊之間是以流水線的方式實現(xiàn)功能的。流水線，指的是一個用戶請求，由多個模塊組合各自的功能依次實現(xiàn)完成的。比如：第一個模塊只負責(zé)分析請求首部，第二個模塊只負責(zé)查找數(shù)據(jù)，第三個模塊只負責(zé)壓縮數(shù)據(jù)，依次完成各自工作。來實現(xiàn)整個工作的完成。 他們是如何實現(xiàn)熱部署的呢？其實是這樣的，我們前面說master不負責(zé)具體的工作，而是調(diào)用worker工作，他只是負責(zé)讀取配置文件，因此當(dāng)一個模塊修改或者配置文件發(fā)生變化，是由master進行讀取，因此此時不會影響到worker工作。在master進行讀取配置文件之后，不會立即把修改的配置文件告知worker。而是讓被修改的worker繼續(xù)使用老的配置文件工作，當(dāng)worker工作完畢之后，直接殺死這個子進程，更換新的子進程，使用新的規(guī)則。

3.3 HAProxy

HAProxy也是使用較多的一款負載均衡軟件。HAProxy提供高可用性、負載均衡以及基于TCP和HTTP應(yīng)用的代理，支持虛擬主機，是免費、快速并且可靠的一種解決方案。特別適用于那些負載特大的web站點。運行模式使得它可以很簡單安全的整合到當(dāng)前的架構(gòu)中，同時可以保護你的web服務(wù)器不被暴露到網(wǎng)絡(luò)上。 HAProxy是一個使用C語言編寫的自由及開放源代碼軟件，其提供高可用性、負載均衡，以及基于TCP和HTTP的應(yīng)用程序代理。 Haproxy主要用來做七層負載均衡。

4 常見負載均衡算法

上面介紹負載均衡技術(shù)的時候提到過，負載均衡服務(wù)器在決定將請求轉(zhuǎn)發(fā)到具體哪臺真實服務(wù)器的時候，是通過負載均衡算法來實現(xiàn)的。負載均衡算法可以分為兩類：靜態(tài)負載均衡算法和動態(tài)負載均衡算法。

靜態(tài)負載均衡算法包括：輪詢，比率，優(yōu)先權(quán)

動態(tài)負載均衡算法包括: 最少連接數(shù),最快響應(yīng)速度，觀察方法，預(yù)測法，動態(tài)性能分配，動態(tài)服務(wù)器補充，服務(wù)質(zhì)量，服務(wù)類型，規(guī)則模式。

輪詢（Round Robin）：順序循環(huán)將請求一次順序循環(huán)地連接每個服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生第二到第7 層的故障，BIG-IP 就把其從順序循環(huán)隊列中拿出，不參加下一次的輪詢，直到其恢復(fù)正常。 以輪詢的方式依次請求調(diào)度不同的服務(wù)器； 實現(xiàn)時，一般為服務(wù)器帶上權(quán)重；這樣有兩個好處： 針對服務(wù)器的性能差異可分配不同的負載； 當(dāng)需要將某個結(jié)點剔除時，只需要將其權(quán)重設(shè)置為0即可； 優(yōu)點：實現(xiàn)簡單、高效；易水平擴展； 缺點：請求到目的結(jié)點的不確定，造成其無法適用于有寫的場景（緩存，數(shù)據(jù)庫寫） 應(yīng)用場景：數(shù)據(jù)庫或應(yīng)用服務(wù)層中只有讀的場景； 隨機方式：請求隨機分布到各個結(jié)點；在數(shù)據(jù)足夠大的場景能達到一個均衡分布； 優(yōu)點：實現(xiàn)簡單、易水平擴展； 缺點：同Round Robin，無法用于有寫的場景； 應(yīng)用場景：數(shù)據(jù)庫負載均衡，也是只有讀的場景；

哈希方式：根據(jù)key來計算需要落在的結(jié)點上，可以保證一個同一個鍵一定落在相同的服務(wù)器上； 優(yōu)點：相同key一定落在同一個結(jié)點上，這樣就可用于有寫有讀的緩存場景； 缺點：在某個結(jié)點故障后，會導(dǎo)致哈希鍵重新分布，造成命中率大幅度下降； 解決：一致性哈希 or 使用keepalived保證任何一個結(jié)點的高可用性，故障后會有其它結(jié)點頂上來； 應(yīng)用場景：緩存，有讀有寫；

一致性哈希：在服務(wù)器一個結(jié)點出現(xiàn)故障時，受影響的只有這個結(jié)點上的key，最大程度的保證命中率； 如twemproxy中的ketama方案； 生產(chǎn)實現(xiàn)中還可以規(guī)劃指定子key哈希，從而保證局部相似特征的鍵能分布在同一個服務(wù)器上； 優(yōu)點：結(jié)點故障后命中率下降有限； 應(yīng)用場景：緩存；

根據(jù)鍵的范圍來負載：根據(jù)鍵的范圍來負載，前1億個鍵都存放到第一個服務(wù)器，1~2億在第二個結(jié)點； 優(yōu)點：水平擴展容易，存儲不夠用時，加服務(wù)器存放后續(xù)新增數(shù)據(jù)； 缺點：負載不均；數(shù)據(jù)庫的分布不均衡；（數(shù)據(jù)有冷熱區(qū)分，一般最近注冊的用戶更加活躍，這樣造成后續(xù)的服務(wù)器非常繁忙，而前期的結(jié)點空閑很多） 適用場景：數(shù)據(jù)庫分片負載均衡；

根據(jù)鍵對服務(wù)器結(jié)點數(shù)取模來負載：根據(jù)鍵對服務(wù)器結(jié)點數(shù)取模來負載；比如有4臺服務(wù)器，key取模為0的落在第一個結(jié)點，1落在第二個結(jié)點上。 優(yōu)點：數(shù)據(jù)冷熱分布均衡，數(shù)據(jù)庫結(jié)點負載均衡分布； 缺點：水平擴展較難； 適用場景：數(shù)據(jù)庫分片負載均衡；

純動態(tài)結(jié)點負載均衡：根據(jù)CPU、IO、網(wǎng)絡(luò)的處理能力來決策接下來的請求如何調(diào)度； 優(yōu)點：充分利用服務(wù)器的資源，保證個結(jié)點上負載處理均衡； 缺點：實現(xiàn)起來復(fù)雜，真實使用較少；

不用主動負載均衡：使用消息隊列轉(zhuǎn)為異步模型，將負載均衡的問題消滅；負載均衡是一種推模型，一直向你發(fā)數(shù)據(jù)，那么，將所有的用戶請求發(fā)到消息隊列中，所有的下游結(jié)點誰空閑，誰上來取數(shù)據(jù)處理；轉(zhuǎn)為拉模型之后，消除了對下行結(jié)點負載的問題； 優(yōu)點：通過消息隊列的緩沖，保護后端系統(tǒng)，請求劇增時不會沖垮后端服務(wù)器； 水平擴展容易，加入新結(jié)點后，直接取queue即可； 缺點：不具有實時性； 應(yīng)用場景：不需要實時返回的場景； 比如，12036下訂單后，立刻返回提示信息：您的訂單進去排隊了…等處理完畢后，再異步通知；

比率（Ratio）：給每個服務(wù)器分配一個加權(quán)值為比例，根椐這個比例，把用戶的請求分配到每個服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生第二到第7 層的故障，BIG-IP 就把其從服務(wù)器隊列中拿出，不參加下一次的用戶請求的分配, 直到其恢復(fù)正常。

優(yōu)先權(quán)（Priority）：給所有服務(wù)器分組,給每個組定義優(yōu)先權(quán)，BIG-IP 用戶的請求，分配給優(yōu)先級最高的服務(wù)器組（在同一組內(nèi)，采用輪詢或比率算法，分配用戶的請求）；當(dāng)最高優(yōu)先級中所有服務(wù)器出現(xiàn)故障，BIG-IP 才將請求送給次優(yōu)先級的服務(wù)器組。這種方式，實際為用戶提供一種熱備份的方式。

最少的連接方式（Least Connection）：傳遞新的連接給那些進行最少連接處理的服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生第二到第7 層的故障，BIG-IP 就把其從服務(wù)器隊列中拿出，不參加下一次的用戶請求的分配, 直到其恢復(fù)正常。

最快模式（Fastest）：傳遞連接給那些響應(yīng)最快的服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生第二到第7 層的故障，BIG-IP 就把其從服務(wù)器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復(fù)正常。

觀察模式（Observed）：連接數(shù)目和響應(yīng)時間以這兩項的最佳平衡為依據(jù)為新的請求選擇服務(wù)器。當(dāng)其中某個服務(wù)器發(fā)生第二到第7 層的故障，BIG-IP就把其從服務(wù)器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復(fù)正常。

預(yù)測模式（Predictive）：BIG-IP利用收集到的服務(wù)器當(dāng)前的性能指標(biāo)，進行預(yù)測分析，選擇一臺服務(wù)器在下一個時間片內(nèi)，其性能將達到最佳的服務(wù)器相應(yīng)用戶的請求。(被BIG-IP 進行檢測)

動態(tài)性能分配(Dynamic Ratio-APM):BIG-IP 收集到的應(yīng)用程序和應(yīng)用服務(wù)器的各項性能參數(shù)，動態(tài)調(diào)整流量分配。

動態(tài)服務(wù)器補充(Dynamic Server Act.):當(dāng)主服務(wù)器群中因故障導(dǎo)致數(shù)量減少時，動態(tài)地將備份服務(wù)器補充至主服務(wù)器群。

服務(wù)質(zhì)量(QoS）:按不同的優(yōu)先級對數(shù)據(jù)流進行分配。

服務(wù)類型(ToS): 按不同的服務(wù)類型（在Type of Field中標(biāo)識）負載均衡對數(shù)據(jù)流進行分配。

規(guī)則模式：針對不同的數(shù)據(jù)流設(shè)置導(dǎo)向規(guī)則，用戶可自行。

負載均衡的幾種算法Java實現(xiàn)代碼

輪詢

 package com.boer.tdf.act.test;
 import java.util.ArrayList;
import java.util.HashMap;
import java.util.Map;
import java.util.Set;
 /**
 * 負載均衡算法，輪詢法.
 */
public class TestRoundRobin {
 static MapserverWeigthMap  = new HashMap();
 static {
 serverWeigthMap.put("192.168.1.12", 1);
 serverWeigthMap.put("192.168.1.13", 1);
 serverWeigthMap.put("192.168.1.14", 2);
 serverWeigthMap.put("192.168.1.15", 2);
 serverWeigthMap.put("192.168.1.16", 3);
 serverWeigthMap.put("192.168.1.17", 3);
 serverWeigthMap.put("192.168.1.18", 1);
 serverWeigthMap.put("192.168.1.19", 2);
 }
 Integer  pos = 0;
 public  String roundRobin() {
 // 重新建立一個map,避免出現(xiàn)由於服務(wù)器上線和下線導(dǎo)致的並發(fā)問題
 MapserverMap  = new HashMap();
 serverMap.putAll(serverWeigthMap);
 // 獲取ip列表list
 SetkeySet = serverMap.keySet();
 ArrayListkeyList = new ArrayList();
 keyList.addAll(keySet);
 String server = null;
 synchronized (pos) {
 if(pos >=keySet.size()){
 pos = 0;
 }
 server = keyList.get(pos);
 pos ++;
 }
 return server;
 }
 public static void main(String[] args) {
 TestRoundRobin robin = new TestRoundRobin();
 for (int i = 0; i < 20; i++) {
 String serverIp = robin.roundRobin();
 System.out.println(serverIp);
 }
 }
 /**
 * 運行結(jié)果:
 * 192.168.1.12
 192.168.1.14
 192.168.1.13
 192.168.1.16
 192.168.1.15
 192.168.1.18
 192.168.1.17
 192.168.1.19
 192.168.1.12
 192.168.1.14
 192.168.1.13
 192.168.1.16
 192.168.1.15
 192.168.1.18
 192.168.1.17
 192.168.1.19
 192.168.1.12
 192.168.1.14
 192.168.1.13
 192.168.1.16
 */
 }

加權(quán)隨機負載均衡算法

 package com.boer.tdf.act.test;
 import java.util.*;
 /**
 * 加權(quán)隨機負載均衡算法.
 */
public class TestWeightRandom {
 static MapserverWeigthMap  = new HashMap();
 static {
 serverWeigthMap.put("192.168.1.12", 1);
 serverWeigthMap.put("192.168.1.13", 1);
 serverWeigthMap.put("192.168.1.14", 2);
 serverWeigthMap.put("192.168.1.15", 2);
 serverWeigthMap.put("192.168.1.16", 3);
 serverWeigthMap.put("192.168.1.17", 3);
 serverWeigthMap.put("192.168.1.18", 1);
 serverWeigthMap.put("192.168.1.19", 2);
 }
 public static String weightRandom()
 {
 // 重新建立一個map,避免出現(xiàn)由於服務(wù)器上線和下線導(dǎo)致的並發(fā)問題
 MapserverMap  = new HashMap();
 serverMap.putAll(serverWeigthMap);
 // 獲取ip列表list
 SetkeySet = serverMap.keySet();
 Iteratorit = keySet.iterator();
 ListserverList = new ArrayList();
 while (it.hasNext()) {
 String server = it.next();
 Integer weight = serverMap.get(server);
 for (int i = 0; i < weight; i++) {
 serverList.add(server);
 }
 }
 Random random = new Random();
 int randomPos = random.nextInt(serverList.size());
 String server = serverList.get(randomPos);
 return server;
 }
 public static void main(String[] args) {
 String serverIp = weightRandom();
 System.out.println(serverIp);
 /**
 * 運行結(jié)果:
 * 192.168.1.16
 */
 }
 }隨機負載均衡算法 package com.boer.tdf.act.test;
 import java.util.*;
 /**
 * 隨機負載均衡算法.
 */
public class TestRandom {
 static MapserverWeigthMap  = new HashMap();
 static {
 serverWeigthMap.put("192.168.1.12", 1);
 serverWeigthMap.put("192.168.1.13", 1);
 serverWeigthMap.put("192.168.1.14", 2);
 serverWeigthMap.put("192.168.1.15", 2);
 serverWeigthMap.put("192.168.1.16", 3);
 serverWeigthMap.put("192.168.1.17", 3);
 serverWeigthMap.put("192.168.1.18", 1);
 serverWeigthMap.put("192.168.1.19", 2);
 }
 public static String random() {
 // 重新建立一個map,避免出現(xiàn)由於服務(wù)器上線和下線導(dǎo)致的並發(fā)問題
 MapserverMap  = new HashMap();
 serverMap.putAll(serverWeigthMap);
 // 獲取ip列表list
 SetkeySet = serverMap.keySet();
 ArrayListkeyList = new ArrayList();
 keyList.addAll(keySet);
 Random random = new Random();
 int randomPos = random.nextInt(keyList.size());
 String server = keyList.get(randomPos);
 return server;
 }
 public static void main(String[] args) {
 String serverIp = random();
 System.out.println(serverIp);
 }
 /**
 * 運行結(jié)果:
 * 192.168.1.16
 */
 }負載均衡 ip_hash算法 package com.boer.tdf.act.test;
 import java.util.ArrayList;
import java.util.HashMap;
import java.util.Map;
import java.util.Set;
 /**
 * 負載均衡 ip_hash算法.
 */
public class TestIpHash {
 static MapserverWeigthMap  = new HashMap();
 static {
 serverWeigthMap.put("192.168.1.12", 1);
 serverWeigthMap.put("192.168.1.13", 1);
 serverWeigthMap.put("192.168.1.14", 2);
 serverWeigthMap.put("192.168.1.15", 2);
 serverWeigthMap.put("192.168.1.16", 3);
 serverWeigthMap.put("192.168.1.17", 3);
 serverWeigthMap.put("192.168.1.18", 1);
 serverWeigthMap.put("192.168.1.19", 2);
 }
 /**
 * 獲取請求服務(wù)器地址
 * @param remoteIp 負載均衡服務(wù)器ip
 * @return
 */
 public static String ipHash(String remoteIp) {
 // 重新建立一個map,避免出現(xiàn)由於服務(wù)器上線和下線導(dǎo)致的並發(fā)問題
 MapserverMap  = new HashMap();
 serverMap.putAll(serverWeigthMap);
 // 獲取ip列表list
 SetkeySet = serverMap.keySet();
 ArrayListkeyList = new ArrayList();
 keyList.addAll(keySet);
 int hashCode =remoteIp.hashCode();
 int serverListSize = keyList.size();
 int serverPos = hashCode % serverListSize;
 return keyList.get(serverPos);
 }
 public static void main(String[] args) {
 String serverIp = ipHash("192.168.1.12");
 System.out.println(serverIp);
 /**
 * 運行結(jié)果:
 * 192.168.1.18
 */
 }
 }

看完上述內(nèi)容是否對您有幫助呢？如果還想對相關(guān)知識有進一步的了解或閱讀更多相關(guān)文章，請關(guān)注億速云行業(yè)資訊頻道，感謝您對億速云的支持。