搞懂分佈式技術10：LVS實現負載均衡的原理與實踐
- 2019 年 12 月 2 日
- 筆記
原創：劉欣 碼農翻身 4月23日
本文內容參考網絡，侵刪
本系列文章將整理到我在GitHub上的《Java面試指南》倉庫
https://github.com/h2pl/Java-Tutorial
文章將同步到我的個人博客：
www.how2playlife.com
該系列博文會告訴你什麼是分佈式系統，這對後端工程師來說是很重要的一門學問，我們會逐步了解常見的分佈式技術、以及一些較為常見的分佈式系統概念，同時也需要進一步了解zookeeper、分佈式事務、分佈式鎖、負載均衡等技術，以便讓你更完整地了解分佈式技術的具體實戰方法，為真正應用分佈式技術做好準備。
如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯繫作者，歡迎你參與本系列博文的創作和修訂。
負載均衡的原理
這是1998年一個普通的上午。
一上班，老闆就把張大胖叫進了辦公室，一邊舒服地喝茶一邊發難：「大胖啊，我們公司開發的這個網站，現在怎麼越來越慢了？」
還好張大胖也注意到了這個問題，他早有準備，一臉無奈地說：「唉，我昨天檢查了一下系統，現在的訪問量已經越來越大了，無論是CPU，還是硬盤、內存都不堪重負了，高峰期的響應速度越來越慢。」
頓了一下，他試探地問道：「老闆，能不能買個好機器？把現在的『老破小』服務器給替換掉。我聽說IBM的服務器挺好的，性能強勁，要不來一台？」 （碼農翻身註：這叫垂直擴展 Scale Up）
「好你個頭，你知道那機器得多貴嗎？! 我們小公司，用不起啊！」 摳門的老闆立刻否決。 「這……」 大胖表示黔驢技窮了。 「你去和CTO Bill 商量下， 明天給我弄個方案出來。」
老闆不管過程，只要結果。
隱藏真實服務器
大胖悻悻地去找Bill。 他將老闆的指示聲情並茂地做了傳達。
Bill笑了：「我最近也在思考這件事，想和你商量一下，看看能不能買幾台便宜的服務器，把系統多部署幾份，橫向擴展(Scale Out)一下。」
橫向擴展？張大胖心中尋思着，如果把系統部署到幾個服務器上，用戶的訪問請求就可以分散到各個服務器，那單台服務器的壓力就小得多了。
「可是，」 張大胖問道 ，「機器多了，每個機器一個IP， 用戶可能就迷糊了，到底訪問哪一個？」
「肯定不能把這些服務器暴露出去，從客戶角度看來，最好是只有一個服務器。」 Bill 說道。
張大胖眼前一亮， 突然有了主意：「有了！我們有個中間層啊，對，就是DNS，我們可以設置一下，讓我們網站的域名映射到多個服務器的IP，用戶面對的是我們系統的域名，然後我們可以採用一種輪詢的方式， 用戶1的機器做域名解析的時候，DNS返回IP1, 用戶2的機器做域名解析的時候，DNS返回IP2…… 這樣不就可以實現各個機器的負載相對均衡了嗎？」
Bill 思考片刻，發現了漏洞：「這樣做有個很要命的問題，由於DNS這個分層的系統中有緩存，用戶端的機器也有緩存，如果某個機器出故障，域名解析仍然會返回那個出問題機器的IP，那所有訪問該機器的用戶都會出問題， 即使我們把這個機器的IP從DNS中刪除也不行， 這就麻煩了。」
張大胖確實是沒想到這個緩存帶來的問題， 他撓撓頭：「那就不好辦了。」
偷天換日
「要不我們自己開發一個軟件實現負載均衡怎麼樣？」 Bill另闢蹊徑。
為了展示自己的想法， 他在白板上畫了一張圖， 「看到中間那個藍色服務器沒有，我們可以把它稱為Load Balancer （簡稱LB）， 用戶的請求都發給他，然後它再發給各個服務器。」
張大胖仔細審視這個圖。
Load Balancer 簡稱LB ， 有兩個IP，一個對外（115.39.19.22），一個對內(192.168.0.100)。用戶看到的是那個對外的IP。後面的真正提供服務的服務器有三個，稱為RS1, RS2,RS3， 他們的網關都指向LB。
「但是怎麼轉發請求呢？嗯， 用戶的請求到底是什麼東西？」 張大胖迷糊了。
「你把計算機網絡都忘了吧？就是用戶發過來的數據包嘛！你看這個層層封裝的數據包，用戶發了一個HTTP的請求，想要訪問我們網站的首頁，這個HTTP請求被放到一個TCP報文中，再被放到一個IP數據報中， 最終的目的地就是我們的Load Balancer（115.39.19.22）。」
（註：客戶發給LB的數據包， 沒有畫出數據鏈路層的幀）
「但是這個數據包一看就是發給Load Balancer的， 怎麼發給後面的服務器？」
Bill 說：「可以偷天換日，比如Load Balancer想把這個數據包發給RS1（192.168.0.10）, 就可以做點手腳，把這個數據包改成這樣， 然後這個IP數據包就可以轉發給RS1去處理了。」
（LB動了手腳，把目的地IP和端口改為RS1的）
「RS1處理完了，要返回首頁的HTML，還要把HTTP報文層層封裝：」 張大胖明白怎麼回事了：
（RS1處理完了，要發送結果給客戶端）
「由於LB是網關，它還會收到這個數據包，它就可以再次施展手段，把源地址和源端口都替換為自己的，然後發給客戶就可以了。」
(LB再次動手腳，把源地址和端口改成自己的， 讓客戶端毫無察覺)
張大胖總結了一下數據的流向： 客戶端 –> Load Balancer –> RS –> Load Balancer –> 客戶端
他興奮地說：「這招瞞天過海真是妙啊，客戶端根本就感受不到後面有好幾台服務器在工作，它一直以為只有Load Balancer在幹活。」
Bill此刻在思考Load Balancer 怎麼樣才能選取後面的各個真實的服務器， 可以有很多種策略，他在白板上寫到：
輪詢：這個最簡單，就是一個挨一個輪換。
加權輪詢：為了應對某些服務器性能好，可以讓他們的權重高一點，被選中的幾率大一點。
最少連接：哪個服務器處理的連接少，就發給誰。
加權最少連接：在最少連接的基礎上，也加上權重 …… 還有些其他的算法和策略，以後慢慢想。
四層還是七層?
張大胖卻想到了另外一個問題：對於用戶的一個請求來說，可能會被分成多個數據包來發送， 如果這些數據包被我們的Load Balancer發到了不同的機器上，那就完全亂套了啊！他把自己的想法告訴了Bill。
Bill說：「這個問題很好啊，我們的Load Balancer必須得維護一個表，這個表需要記錄下客戶端的數據包被我們轉發到了哪個真實的服務器上， 這樣當下一個數據包到來時，我們就可以把它轉發到同一個服務器上去。」
「看來這個負載均衡軟件需要是面向連接的，也就是OSI網絡體系的第4層， 可以稱為四層負載均衡」Bill做了一個總結。
「既然有四層負載均衡，那是不是也可以搞個七層的負載均衡啊？」 張大胖突發奇想。
「那是肯定的，如果我們的Load Balancer把HTTP層的報文數據取出來，根據其中的URL，瀏覽器，語言等信息，把請求分發到後面真實的服務器去，那就是七層的負載均衡了。不過我們現階段先實現一個四層的吧，七層的以後再說。」
Bill 吩咐張大胖組織人力把這個負載均衡軟件給開發出來。
張大胖不敢怠慢，由於涉及到協議的細節問題，張大胖還買了幾本書：《TCP/IP詳解》 卷一,卷二,卷三， 帶着人快速複習了C語言， 然後開始瘋狂開發。
責任分離
三個月後，Load Balancer的第一版開發出來了，這是運行在Linux上的一個軟件， 公司試用了一下，感覺還真是不錯，僅僅用幾台便宜的服務器就可以實現負載均衡了。
老闆看到沒花多少錢就解決了問題，非常滿意，給張大胖所在的開發組發了1000塊錢獎金，組織大家出去搓了一頓。
張大胖他們看到老闆很摳門，雖略有不滿，但是想到通過這個軟件的開發，學到了很多底層的知識，尤其是TCP協議，也就忍了。
可是好景不長，張大胖發現這個Load Balancer存在這瓶頸：所有的流量都要通過它，它要修改客戶發來的數據包， 還要修改發給客戶的數據包。
網絡訪問還有個極大的特點，那就是請求報文較短而響應報文往往包含大量的數據。這是很容易理解的，一個HTTP GET請求短得可憐，可是返回的HTML卻是極長 – 這就進一步加劇了Load Balancer修改數據包的工作。
張大胖趕緊去找Bill ，Bill說：「這確實是個問題，我們把請求和響應分開處理吧，讓Load Balancer只處理請求，讓各個服務器把響應直接發給客戶端，這樣瓶頸不就消除了嗎？」
「怎麼分開處理？」
「首先讓所有的服務器都有同一個IP， 我們把他稱為VIP吧（如圖中115.39.19.22）。」
張大胖通過第一版Load Balancer的開發，積累了豐富的經驗。
他問道：「你這是把每個實際服務器的loopback都綁定了那個VIP， 不過有問題啊，這麼多服務器都有同樣的IP , 當IP數據包來的時候，到底應該由哪個服務器來處理？」
張大胖看到了客戶端的HTTP報文再次被封裝儲層TCP報文，端口號是80， 然後IP數據報中的目的地是115.39.19.22(VIP)。
圖中的問號是目的地的MAC地址， 該怎麼得到呢？
對， 是使用ARP協議，把一個IP地址（115.39.19.22）給廣播出去，然後具有此IP機器就會回復自己的MAC地址。但是現在有好幾台機器都有同一個IP（115.39.19.22）， 怎麼辦？
Bill 說道：「我們只讓Load Balancer 響應這個VIP地址（115.39.19.22）的ARP請求，對於RS1,RS2,RS3, 抑制住對這個VIP地址的ARP響應，不就可以唯一地確定Load Balancer了？」
原來如此！張大胖恍然大悟。
既然Load Balancer得到了這個IP數據包， 它就可以用某個策略從RS1, RS2,RS3中選取一個服務器，例如RS1（192.168.0.10），把IP數據報原封不動， 封裝成數據鏈路層的包（目的地是RS1的MAC地址），直接轉發就可以了。
RS1（192.168.0.10）這個服務器收到了數據包，拆開一看，目的地IP是115.39.19.22，是自己的IP， 那就可以處理了。
處理完了以後，RS1可以直接響應發回給客戶端，完全不用再通過Load Balancer。因為自己的地址就是115.39.19.22。
對於客戶端來說，它看到的還是那個唯一的地址115.39.19.22， 並不知道後台發生了什麼事情。
Bill補充到：「由於Load Balancer 根本不會修改IP數據報，其中的TCP的端口號自然也不會修改，這就要求RS1, RS2,RS3上的端口號必須得和Load Balancer一致才行。」
像之前一樣，張大胖總結了一下數據的流向：
客戶端 –> Load Balancer –> RS –> 客戶端
Bill 說道：「怎麼樣？這個辦法還可以吧？」
張大胖又想了想，這種方式似乎沒有漏洞，並且效率很高，Load Balancer只負責把用戶請求發給特定的服務器就萬事大吉了， 剩下的事由具體的服務器來處理，和它沒有關係了。
他高興地說：「不錯，我着手帶人去實現了。」
後記： 本文所描述的，其實就是著名開源軟件LVS的原理，上面講的兩種負載均衡的方式，就是LVS的NAT和DR。LVS是章文嵩博士在1998年5月成立的自由軟件項目，現在已經是Linux內核的一部分。想想那時候我還在不亦樂乎地折騰個人網頁，學會安裝和使用Linux 沒多久 , 服務器端開發也僅限於ASP，像LVS這種負載均衡的概念壓根就沒有聽說過。 編程語言可以學，差距也能彌補，但是這種境界和眼光的差距，簡直就是巨大的鴻溝，難以跨越啊！ 讀故事筆記：關於LVS的文章也讀過幾篇，往往只是記住了概念，不能設身處地的思考為何而來，劉欣老師每每都能以人物設定的場景，讓我再次回到那個年代去思考、推演，還原當時如何一步步的演進成後來的LVS。
本人也混跡軟件開發十幾年，多數時間都是做着行業領域的軟件開發，自我安慰是做着xx行業與計算機行業的交叉領域，實則一直未能深入計算機系統領域。行業應用軟件開發，行業知識本身就牽扯了太多了精力，軟件開發更多選擇一種合適的架構來完成系統的設計、開發和維護。如你要成為一個計算機高手，有機會還是應當就計算機某一個領域深入研究，如Linux內核、搜索、圖形圖像、數據庫、分佈式存儲，當然還有人工智能等等。
分佈式架構實踐——負載均衡
也許當我老了，也一樣寫代碼；不為別的，只為了愛好。
1 什麼是負載均衡（Load balancing）
在網站創立初期，我們一般都使用單台機器對台提供集中式服務，但是隨着業務量越來越大，無論是性能上還是穩定性上都有了更大的挑戰。這時候我們就會想到通過擴容的方式來提供更好的服務。我們一般會把多台機器組成一個集群對外提供服務。然而，我們的網站對外提供的訪問入口都是一個的，比如www.taobao.com。那麼當用戶在瀏覽器輸入www.taobao.com的時候如何將用戶的請求分發到集群中不同的機器上呢，這就是負載均衡在做的事情。
當前大多數的互聯網系統都使用了服務器集群技術，集群即將相同服務部署在多台服務器上構成一個集群整體對外提供服務，這些集群可以是Web應用服務器集群，也可以是數據庫服務器集群，還可以是分佈式緩存服務器集群等等。
在實際應用中，在Web服務器集群之前總會有一台負載均衡服務器，負載均衡設備的任務就是作為Web服務器流量的入口，挑選最合適的一台Web服務器，將客戶端的請求轉發給它處理，實現客戶端到真實服務端的透明轉發。最近幾年很火的「雲計算」以及分佈式架構，本質上也是將後端服務器作為計算資源、存儲資源，由某台管理服務器封裝成一個服務對外提供，客戶端不需要關心真正提供服務的是哪台機器，在它看來，就好像它面對的是一台擁有近乎無限能力的服務器，而本質上，真正提供服務的，是後端的集群。 軟件負載解決的兩個核心問題是：選誰、轉發，其中最著名的是LVS（Linux Virtual Server）。
一個典型的互聯網應用的拓撲結構是這樣的：
2 負載均衡分類
現在我們知道，負載均衡就是一種計算機網絡技術，用來在多個計算機（計算機集群）、網絡連接、CPU、磁碟驅動器或其他資源中分配負載，以達到最佳化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。那麼，這種計算機技術的實現方式有多種。大致可以分為以下幾種，其中最常用的是四層和七層負載均衡：
二層負載均衡 負載均衡服務器對外依然提供一個VIP（虛IP），集群中不同的機器採用相同IP地址，但是機器的MAC地址不一樣。當負載均衡服務器接受到請求之後，通過改寫報文的目標MAC地址的方式將請求轉發到目標機器實現負載均衡。
三層負載均衡 和二層負載均衡類似，負載均衡服務器對外依然提供一個VIP（虛IP），但是集群中不同的機器採用不同的IP地址。當負載均衡服務器接受到請求之後，根據不同的負載均衡算法，通過IP將請求轉發至不同的真實服務器。
四層負載均衡 四層負載均衡工作在OSI模型的傳輸層，由於在傳輸層，只有TCP/UDP協議，這兩種協議中除了包含源IP、目標IP以外，還包含源端口號及目的端口號。四層負載均衡服務器在接受到客戶端請求後，以後通過**修改數據包的地址信息（IP+端口號）**將流量轉發到應用服務器。
七層負載均衡 七層負載均衡工作在OSI模型的應用層，應用層協議較多，常用http、radius、dns等。七層負載就可以基於這些協議來負載。這些應用層協議中會包含很多有意義的內容。比如同一個Web服務器的負載均衡，除了根據IP加端口進行負載外，還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。
對於一般的應用來說，有了Nginx就夠了。Nginx可以用於七層負載均衡。但是對於一些大的網站，一般會採用DNS+四層負載+七層負載的方式進行多層次負載均衡。
3 常用負載均衡工具
硬件負載均衡性能優越，功能全面，但是價格昂貴，一般適合初期或者土豪級公司長期使用。因此軟件負載均衡在互聯網領域大量使用。常用的軟件負載均衡軟件有Nginx，Lvs，HaProxy等。Nginx/LVS/HAProxy是目前使用最廣泛的三種負載均衡軟件。
3.1 LVS
LVS（Linux Virtual Server），也就是Linux虛擬服務器, 是一個由章文嵩博士發起的自由軟件項目。使用LVS技術要達到的目標是：通過LVS提供的負載均衡技術和Linux操作系統實現一個高性能、高可用的服務器群集，它具有良好可靠性、可擴展性和可操作性。從而以低廉的成本實現最優的服務性能。LVS主要用來做四層負載均衡。
LVS架構 LVS架設的服務器集群系統有三個部分組成：最前端的負載均衡層（Loader Balancer），中間的服務器群組層，用Server Array表示，最底層的數據共享存儲層，用Shared Storage表示。在用戶看來所有的應用都是透明的，用戶只是在使用一個虛擬服務器提供的高性能服務。
LVS的體系架構.png
LVS的各個層次的詳細介紹：
Load Balancer層：位於整個集群系統的最前端，由一台或者多台負載調度器（Director Server）組成，LVS模塊就安裝在Director Server上，而Director的主要作用類似於一個路由器，它含有完成LVS功能所設定的路由表，通過這些路由表把用戶的請求分發給Server Array層的應用服務器（Real Server）上。同時，在Director Server上還要安裝對Real Server服務的監控模塊Ldirectord，此模塊用於監測各個Real Server服務的健康狀況。在Real Server不可用時把它從LVS路由表中剔除，恢復時重新加入。
Server Array層：由一組實際運行應用服務的機器組成，Real Server可以是WEB服務器、MAIL服務器、FTP服務器、DNS服務器、視頻服務器中的一個或者多個，每個Real Server之間通過高速的LAN或分佈在各地的WAN相連接。在實際的應用中，Director Server也可以同時兼任Real Server的角色。
Shared Storage層：是為所有Real Server提供共享存儲空間和內容一致性的存儲區域，在物理上，一般有磁盤陣列設備組成，為了提供內容的一致性，一般可以通過NFS網絡文件系統共享數 據，但是NFS在繁忙的業務系統中，性能並不是很好，此時可以採用集群文件系統，例如Red hat的GFS文件系統，oracle提供的OCFS2文件系統等。
從整個LVS結構可以看出，Director Server是整個LVS的核心，目前，用於Director Server的操作系統只能是Linux和FreeBSD，linux2.6內核不用任何設置就可以支持LVS功能，而FreeBSD作為 Director Server的應用還不是很多，性能也不是很好。對於Real Server，幾乎可以是所有的系統平台，Linux、windows、Solaris、AIX、BSD系列都能很好的支持。
3.2 Nginx
Nginx（發音同engine x）是一個網頁服務器，它能反向代理HTTP, HTTPS, SMTP, POP3, IMAP的協議鏈接，以及一個負載均衡器和一個HTTP緩存。Nginx主要用來做七層負載均衡。 並發性能：官方支持每秒5萬並發，實際國內一般到每秒2萬並發，有優化到每秒10萬並發的。具體性能看應用場景。
特點
模塊化設計：良好的擴展性，可以通過模塊方式進行功能擴展。 高可靠性：主控進程和worker是同步實現的，一個worker出現問題，會立刻啟動另一個worker。 內存消耗低：一萬個長連接（keep-alive）,僅消耗2.5MB內存。 支持熱部署：不用停止服務器，實現更新配置文件，更換日誌文件、更新服務器程序版本。 並發能力強：官方數據每秒支持5萬並發； 功能豐富：優秀的反向代理功能和靈活的負載均衡策略 Nginx的基本工作模式
Nginx的基本工作模式.jpg
一個master進程，生成一個或者多個worker進程。但是這裡master是使用root身份啟動的，因為nginx要工作在80端口。而只有管理員才有權限啟動小於低於1023的端口。master主要是負責的作用只是啟動worker，加載配置文件，負責系統的平滑升級。其它的工作是交給worker。那麼當worker被啟動之後，也只是負責一些web最簡單的工作，而其他的工作都是由worker中調用的模塊來實現的。 模塊之間是以流水線的方式實現功能的。流水線，指的是一個用戶請求，由多個模塊組合各自的功能依次實現完成的。比如：第一個模塊只負責分析請求首部，第二個模塊只負責查找數據，第三個模塊只負責壓縮數據，依次完成各自工作。來實現整個工作的完成。 他們是如何實現熱部署的呢？其實是這樣的，我們前面說master不負責具體的工作，而是調用worker工作，他只是負責讀取配置文件，因此當一個模塊修改或者配置文件發生變化，是由master進行讀取，因此此時不會影響到worker工作**。在master進行讀取配置文件之後，不會立即把修改的配置文件告知worker。而是讓被修改的worker繼續使用老的配置文件工作，當worker工作完畢之後，直接殺死這個子進程，更換新的子進程，使用新的規則。**
3.3 HAProxy
HAProxy也是使用較多的一款負載均衡軟件。HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，是免費、快速並且可靠的一種解決方案。特別適用於那些**負載特大的web站點。**運行模式使得它可以很簡單安全的整合到當前的架構中，同時可以保護你的web服務器不被暴露到網絡上。HAProxy是一個使用C語言編寫的自由及開放源代碼軟件，其提供高可用性、負載均衡，以及基於TCP和HTTP的應用程序代理。Haproxy主要用來做七層負載均衡。
4 常見負載均衡算法
上面介紹負載均衡技術的時候提到過，負載均衡服務器在決定將請求轉發到具體哪台真實服務器的時候，是通過負載均衡算法來實現的。負載均衡算法可以分為兩類：靜態負載均衡算法和動態負載均衡算法。
靜態負載均衡算法包括：輪詢，比率，優先權
動態負載均衡算法包括: 最少連接數,最快響應速度，觀察方法，預測法，動態性能分配，動態服務器補充，服務質量，服務類型，規則模式。
輪詢（Round Robin）：順序循環將請求一次順序循環地連接每個服務器。當其中某個服務器發生第二到第7 層的故障，BIG-IP 就把其從順序循環隊列中拿出，不參加下一次的輪詢，直到其恢復正常。 以輪詢的方式依次請求調度不同的服務器；實現時，一般為服務器帶上權重；這樣有兩個好處： 針對服務器的性能差異可分配不同的負載； 當需要將某個結點剔除時，只需要將其權重設置為0即可； 優點：實現簡單、高效；易水平擴展； 缺點：請求到目的結點的不確定，造成其無法適用於有寫的場景（緩存，數據庫寫） 應用場景：數據庫或應用服務層中只有讀的場景； 隨機方式：請求隨機分佈到各個結點；在數據足夠大的場景能達到一個均衡分佈； 優點：實現簡單、易水平擴展； 缺點：同Round Robin，無法用於有寫的場景； 應用場景：數據庫負載均衡，也是只有讀的場景；
哈希方式：根據key來計算需要落在的結點上，可以保證一個同一個鍵一定落在相同的服務器上； 優點：相同key一定落在同一個結點上，這樣就可用於有寫有讀的緩存場景； 缺點：在某個結點故障後，會導致哈希鍵重新分佈，造成命中率大幅度下降； 解決：一致性哈希 or 使用keepalived保證任何一個結點的高可用性，故障後會有其它結點頂上來； 應用場景：緩存，有讀有寫；
一致性哈希：在服務器一個結點出現故障時，受影響的只有這個結點上的key，最大程度的保證命中率；如twemproxy中的ketama方案；生產實現中還可以規劃指定子key哈希，從而保證局部相似特徵的鍵能分佈在同一個服務器上； 優點：結點故障後命中率下降有限； 應用場景：緩存；
根據鍵的範圍來負載：根據鍵的範圍來負載，前1億個鍵都存放到第一個服務器，1~2億在第二個結點； 優點：水平擴展容易，存儲不夠用時，加服務器存放後續新增數據； 缺點：負載不均；數據庫的分佈不均衡；（數據有冷熱區分，一般最近註冊的用戶更加活躍，這樣造成後續的服務器非常繁忙，而前期的結點空閑很多） 適用場景：數據庫分片負載均衡；
根據鍵對服務器結點數取模來負載：根據鍵對服務器結點數取模來負載；比如有4台服務器，key取模為0的落在第一個結點，1落在第二個結點上。 優點：數據冷熱分佈均衡，數據庫結點負載均衡分佈； 缺點：水平擴展較難； 適用場景：數據庫分片負載均衡；
純動態結點負載均衡：根據CPU、IO、網絡的處理能力來決策接下來的請求如何調度； 優點：充分利用服務器的資源，保證個結點上負載處理均衡； 缺點：實現起來複雜，真實使用較少；
不用主動負載均衡：使用消息隊列轉為異步模型，將負載均衡的問題消滅；負載均衡是一種推模型，一直向你發數據，那麼，將所有的用戶請求發到消息隊列中，所有的下游結點誰空閑，誰上來取數據處理；轉為拉模型之後，消除了對下行結點負載的問題； 優點：通過消息隊列的緩衝，保護後端系統，請求劇增時不會衝垮後端服務器； 水平擴展容易，加入新結點後，直接取queue即可； 缺點：不具有實時性； 應用場景：不需要實時返回的場景； 比如，12036下訂單後，立刻返回提示信息：您的訂單進去排隊了…等處理完畢後，再異步通知；
比率（Ratio）：給每個服務器分配一個加權值為比例，根椐這個比例，把用戶的請求分配到每個服務器。當其中某個服務器發生第二到第7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配, 直到其恢復正常。
優先權（Priority）：給所有服務器分組,給每個組定義優先權，BIG-IP 用戶的請求，分配給優先級最高的服務器組（在同一組內，採用輪詢或比率算法，分配用戶的請求）；當最高優先級中所有服務器出現故障，BIG-IP 才將請求送給次優先級的服務器組。這種方式，實際為用戶提供一種熱備份的方式。
最少的連接方式（Least Connection）：傳遞新的連接給那些進行最少連接處理的服務器。當其中某個服務器發生第二到第7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配, 直到其恢復正常。
最快模式（Fastest）：傳遞連接給那些響應最快的服務器。當其中某個服務器發生第二到第7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。
觀察模式（Observed）：連接數目和響應時間以這兩項的最佳平衡為依據為新的請求選擇服務器。當其中某個服務器發生第二到第7 層的故障，BIG-IP就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。
預測模式（Predictive）：BIG-IP利用收集到的服務器當前的性能指標，進行預測分析，選擇一台服務器在下一個時間片內，其性能將達到最佳的服務器相應用戶的請求。(被BIG-IP 進行檢測)
動態性能分配(Dynamic Ratio-APM):BIG-IP 收集到的應用程序和應用服務器的各項性能參數，動態調整流量分配。
動態服務器補充(Dynamic Server Act.):當主服務器群中因故障導致數量減少時，動態地將備份服務器補充至主服務器群。
服務質量(QoS）:按不同的優先級對數據流進行分配。
服務類型(ToS): 按不同的服務類型（在Type of Field中標識）負載均衡對數據流進行分配。
規則模式：針對不同的數據流設置導向規則，用戶可自行。
負載均衡的幾種算法Java實現代碼
輪詢
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 Map<String,Integer> serverWeigthMap = new HashMap<String,Integer>(); 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,避免出現由於服務器上線和下線導致的並發問題 Map<String,Integer> serverMap = new HashMap<String,Integer>(); serverMap.putAll(serverWeigthMap); // 獲取ip列表list Set<String> keySet = serverMap.keySet(); ArrayList<String> keyList = new ArrayList<String>(); 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); } } /** * 運行結果: * 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 */ }
加權隨機負載均衡算法
package com.boer.tdf.act.test; import java.util.*; /** * 加權隨機負載均衡算法. */ public class TestWeightRandom { static Map<String,Integer> serverWeigthMap = new HashMap<String,Integer>(); 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,避免出現由於服務器上線和下線導致的並發問題 Map<String,Integer> serverMap = new HashMap<String,Integer>(); serverMap.putAll(serverWeigthMap); // 獲取ip列表list Set<String> keySet = serverMap.keySet(); Iterator<String> it = keySet.iterator(); List<String> serverList = new ArrayList<String>(); 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); /** * 運行結果: * 192.168.1.16 */ } }
隨機負載均衡算法
package com.boer.tdf.act.test; import java.util.*; /** * 隨機負載均衡算法. */ public class TestRandom { static Map<String,Integer> serverWeigthMap = new HashMap<String,Integer>(); 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,避免出現由於服務器上線和下線導致的並發問題 Map<String,Integer> serverMap = new HashMap<String,Integer>(); serverMap.putAll(serverWeigthMap); // 獲取ip列表list Set<String> keySet = serverMap.keySet(); ArrayList<String> keyList = new ArrayList<String>(); 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); } /** * 運行結果: * 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 Map<String,Integer> serverWeigthMap = new HashMap<String,Integer>(); 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); } /** * 獲取請求服務器地址 * @param remoteIp 負載均衡服務器ip * @return */ public static String ipHash(String remoteIp) { // 重新建立一個map,避免出現由於服務器上線和下線導致的並發問題 Map<String,Integer> serverMap = new HashMap<String,Integer>(); serverMap.putAll(serverWeigthMap); // 獲取ip列表list Set<String> keySet = serverMap.keySet(); ArrayList<String> keyList = new ArrayList<String>(); 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); /** * 運行結果: * 192.168.1.18 */ } }
