LVS實現(xiàn)負載均衡的原理與實踐是怎樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。
創(chuàng)新互聯(lián)專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務，包含不限于網(wǎng)站建設、成都做網(wǎng)站、金口河網(wǎng)絡推廣、小程序開發(fā)、金口河網(wǎng)絡營銷、金口河企業(yè)策劃、金口河品牌公關、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運營等，從售前售中售后，我們都將竭誠為您服務，您的肯定，是我們最大的嘉獎；創(chuàng)新互聯(lián)為所有大學生創(chuàng)業(yè)者提供金口河建站搭建服務，24小時服務熱線：13518219792，官方網(wǎng)址：www.cdcxhl.com
這是1998年一個普通的上午。
一上班，老板就把張大胖叫進了辦公室，一邊舒服地喝茶一邊發(fā)難：“大胖啊，我們公司開發(fā)的這個網(wǎng)站，現(xiàn)在怎么越來越慢了？ ”
還好張大胖也注意到了這個問題，他早有準備，一臉無奈地說： “唉，我昨天檢查了一下系統(tǒng)，現(xiàn)在的訪問量已經(jīng)越來越大了，無論是CPU，還是硬盤、內(nèi)存都不堪重負了，高峰期的響應速度越來越慢?！?/p>
頓了一下，他試探地問道：“老板，能不能買個好機器？ 把現(xiàn)在的‘老破小’服務器給替換掉。我聽說IBM的服務器挺好的，性能強勁，要不來一臺？”
“好你個頭，你知道那機器得多貴嗎？! 我們小公司，用不起?。 ?摳門的老板立刻否決。 “這……” 大胖表示黔驢技窮了。 “你去和CTO Bill 商量下， 明天給我弄個方案出來。”
老板不管過程，只要結果。
大胖悻悻地去找Bill。 他將老板的指示聲情并茂地做了傳達。
Bill笑了：“我最近也在思考這件事，想和你商量一下，看看能不能買幾臺便宜的服務器，把系統(tǒng)多部署幾份，橫向擴展(Scale Out)一下。 ”
橫向擴展？ 張大胖心中尋思著，如果把系統(tǒng)部署到幾個服務器上，用戶的訪問請求就可以分散到各個服務器，那單臺服務器的壓力就小得多了。
“可是，” 張大胖問道 ，“機器多了，每個機器一個IP， 用戶可能就迷糊了，到底訪問哪一個？”
RS1（192.168.0.10）這個服務器收到了數(shù)據(jù)包，拆開一看，目的地IP是115.39.19.22，是自己的IP， 那就可以處理了。
處理完了以后，RS1可以直接響應發(fā)回給客戶端，完全不用再通過Load Balancer。因為自己的地址就是115.39.19.22。
對于客戶端來說，它看到的還是那個唯一的地址115.39.19.22， 并不知道后臺發(fā)生了什么事情。
Bill補充到：“由于Load Balancer 根本不會修改IP數(shù)據(jù)報，其中的TCP的端口號自然也不會修改，這就要求RS1, RS2,RS3上的端口號必須得和Load Balancer一致才行。”
像之前一樣，張大胖總結了一下數(shù)據(jù)的流向：
客戶端 –> Load Balancer –> RS –> 客戶端
Bill 說道：“怎么樣？ 這個辦法還可以吧？”
張大胖又想了想，這種方式似乎沒有漏洞，并且效率很高，Load Balancer只負責把用戶請求發(fā)給特定的服務器就萬事大吉了， 剩下的事由具體的服務器來處理，和它沒有關系了。
他高興地說：“不錯，我著手帶人去實現(xiàn)了?！?/p>
后記： 本文所描述的，其實就是著名開源軟件LVS的原理，上面講的兩種負載均衡的方式，就是LVS的NAT和DR。 LVS是章文嵩博士在1998年5月成立的自由軟件項目，現(xiàn)在已經(jīng)是Linux內(nèi)核的一部分。想想那時候我還在不亦樂乎地折騰個人網(wǎng)頁，學會安裝和使用Linux 沒多久 , 服務器端開發(fā)也僅限于ASP，像LVS這種負載均衡的概念壓根就沒有聽說過。 編程語言可以學，差距也能彌補，但是這種境界和眼光的差距，簡直就是巨大的鴻溝，難以跨越啊！ 讀故事筆記：關于LVS的文章也讀過幾篇，往往只是記住了概念，不能設身處地的思考為何而來，劉欣老師每每都能以人物設定的場景，讓我再次回到那個年代去思考、推演，還原當時如何一步步的演進成后來的LVS。
本人也混跡軟件開發(fā)十幾年，多數(shù)時間都是做著行業(yè)領域的軟件開發(fā)，自我安慰是做著xx行業(yè)與計算機行業(yè)的交叉領域，實則一直未能深入計算機系統(tǒng)領域。行業(yè)應用軟件開發(fā)，行業(yè)知識本身就牽扯了太多了精力，軟件開發(fā)更多選擇一種合適的架構來完成系統(tǒng)的設計、開發(fā)和維護。如你要成為一個計算機高手，有機會還是應當就計算機某一個領域深入研究，如Linux內(nèi)核、搜索、圖形圖像、數(shù)據(jù)庫、分布式存儲，當然還有人工智能等等。
分布式架構實踐——負載均衡
也許當我老了，也一樣寫代碼；不為別的，只為了愛好。
在網(wǎng)站創(chuàng)立初期，我們一般都使用單臺機器對臺提供集中式服務，但是隨著業(yè)務量越來越大，無論是性能上還是穩(wěn)定性上都有了更大的挑戰(zhàn)。這時候我們就會想到通過擴容的方式來提供更好的服務。我們一般會把多臺機器組成一個集群對外提供服務。然而，我們的網(wǎng)站對外提供的訪問入口都是一個的，比如 www.taobao.com。那么當用戶在瀏覽器輸入 www.taobao.com的時候如何將用戶的請求分發(fā)到集群中不同的機器上呢，這就是負載均衡在做的事情。
當前大多數(shù)的互聯(lián)網(wǎng)系統(tǒng)都使用了服務器集群技術，集群即將相同服務部署在多臺服務器上構成一個集群整體對外提供服務，這些集群可以是Web應用服務器集群，也可以是數(shù)據(jù)庫服務器集群，還可以是分布式緩存服務器集群等等。
在實際應用中，在Web服務器集群之前總會有一臺負載均衡服務器，負載均衡設備的任務就是作為Web服務器流量的入口，挑選最合適的一臺Web服務器，將客戶端的請求轉發(fā)給它處理，實現(xiàn)客戶端到真實服務端的透明轉發(fā)。最近幾年很火的「云計算」以及分布式架構，本質(zhì)上也是將后端服務器作為計算資源、存儲資源，由某臺管理服務器封裝成一個服務對外提供，客戶端不需要關心真正提供服務的是哪臺機器，在它看來，就好像它面對的是一臺擁有近乎無限能力的服務器，而本質(zhì)上，真正提供服務的，是后端的集群。 軟件負載解決的兩個核心問題是：選誰、轉發(fā)，其中最著名的是LVS（Linux Virtual Server）。
一個典型的互聯(lián)網(wǎng)應用的拓撲結構是這樣的：
現(xiàn)在我們知道，負載均衡就是一種計算機網(wǎng)絡技術，用來在多個計算機（計算機集群）、網(wǎng)絡連接、CPU、磁碟驅動器或其他資源中分配負載，以達到最佳化資源使用、最大化吞吐率、最小化響應時間、同時避免過載的目的。那么，這種計算機技術的實現(xiàn)方式有多種。大致可以分為以下幾種，其中最常用的是四層和七層負載均衡：
二層負載均衡負載均衡服務器對外依然提供一個VIP（虛IP），集群中不同的機器采用相同IP地址，但是機器的MAC地址不一樣。當負載均衡服務器接受到請求之后，通過改寫報文的目標MAC地址的方式將請求轉發(fā)到目標機器實現(xiàn)負載均衡。
三層負載均衡和二層負載均衡類似，負載均衡服務器對外依然提供一個VIP（虛IP），但是集群中不同的機器采用不同的IP地址。當負載均衡服務器接受到請求之后，根據(jù)不同的負載均衡算法，通過IP將請求轉發(fā)至不同的真實服務器。
四層負載均衡四層負載均衡工作在OSI模型的傳輸層，由于在傳輸層，只有TCP/UDP協(xié)議，這兩種協(xié)議中除了包含源IP、目標IP以外，還包含源端口號及目的端口號。四層負載均衡服務器在接受到客戶端請求后，以后通過修改數(shù)據(jù)包的地址信息（IP+端口號）將流量轉發(fā)到應用服務器。
七層負載均衡七層負載均衡工作在OSI模型的應用層，應用層協(xié)議較多，常用http、radius、dns等。七層負載就可以基于這些協(xié)議來負載。這些應用層協(xié)議中會包含很多有意義的內(nèi)容。比如同一個Web服務器的負載均衡，除了根據(jù)IP加端口進行負載外，還可根據(jù)七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。
對于一般的應用來說，有了Nginx就夠了。Nginx可以用于七層負載均衡。但是對于一些大的網(wǎng)站，一般會采用DNS+四層負載+七層負載的方式進行多層次負載均衡。
硬件負載均衡性能優(yōu)越，功能全面，但是價格昂貴，一般適合初期或者土豪級公司長期使用。因此軟件負載均衡在互聯(lián)網(wǎng)領域大量使用。常用的軟件負載均衡軟件有Nginx，Lvs，HaProxy等。 Nginx/LVS/HAProxy是目前使用最廣泛的三種負載均衡軟件。
LVS（Linux Virtual Server），也就是Linux虛擬服務器, 是一個由章文嵩博士發(fā)起的自由軟件項目。使用LVS技術要達到的目標是：通過LVS提供的負載均衡技術和Linux操作系統(tǒng)實現(xiàn)一個高性能、高可用的服務器群集，它具有良好可靠性、可擴展性和可操作性。從而以低廉的成本實現(xiàn)最優(yōu)的服務性能。 LVS主要用來做四層負載均衡。
LVS架構LVS架設的服務器集群系統(tǒng)有三個部分組成：最前端的負載均衡層（Loader Balancer），中間的服務器群組層，用Server Array表示，最底層的數(shù)據(jù)共享存儲層，用Shared Storage表示。在用戶看來所有的應用都是透明的，用戶只是在使用一個虛擬服務器提供的高性能服務。
LVS的體系架構.png
LVS的各個層次的詳細介紹：
Load Balancer層：位于整個集群系統(tǒng)的最前端，由一臺或者多臺負載調(diào)度器（Director Server）組成，LVS模塊就安裝在Director Server上，而Director的主要作用類似于一個路由器，它含有完成LVS功能所設定的路由表，通過這些路由表把用戶的請求分發(fā)給Server Array層的應用服務器（Real Server）上。同時，在Director Server上還要安裝對Real Server服務的監(jiān)控模塊Ldirectord，此模塊用于監(jiān)測各個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提供共享存儲空間和內(nèi)容一致性的存儲區(qū)域，在物理上，一般有磁盤陣列設備組成，為了提供內(nèi)容的一致性，一般可以通過NFS網(wǎng)絡文件系統(tǒng)共享數(shù) 據(jù)，但是NFS在繁忙的業(yè)務系統(tǒng)中，性能并不是很好，此時可以采用集群文件系統(tǒng)，例如Red hat的GFS文件系統(tǒng)，oracle提供的OCFS2文件系統(tǒng)等。
從整個LVS結構可以看出，Director Server是整個LVS的核心，目前，用于Director Server的操作系統(tǒng)只能是Linux和FreeBSD，linux2.6內(nèi)核不用任何設置就可以支持LVS功能，而FreeBSD作為 Director Server的應用還不是很多，性能也不是很好。對于Real Server，幾乎可以是所有的系統(tǒng)平臺，Linux、windows、Solaris、AIX、BSD系列都能很好的支持。
Nginx（發(fā)音同engine x）是一個網(wǎng)頁服務器，它能反向代理HTTP, HTTPS, SMTP, POP3, IMAP的協(xié)議鏈接，以及一個負載均衡器和一個HTTP緩存。 Nginx主要用來做七層負載均衡。 并發(fā)性能：官方支持每秒5萬并發(fā)，實際國內(nèi)一般到每秒2萬并發(fā)，有優(yōu)化到每秒10萬并發(fā)的。具體性能看應用場景。
特點
模塊化設計：良好的擴展性，可以通過模塊方式進行功能擴展。 高可靠性：主控進程和worker是同步實現(xiàn)的，一個worker出現(xiàn)問題，會立刻啟動另一個worker。 內(nèi)存消耗低：一萬個長連接（keep-alive）,僅消耗2.5MB內(nèi)存。 支持熱部署：不用停止服務器，實現(xiàn)更新配置文件，更換日志文件、更新服務器程序版本。 并發(fā)能力強：官方數(shù)據(jù)每秒支持5萬并發(fā)； 功能豐富：優(yōu)秀的反向代理功能和靈活的負載均衡策略 Nginx的基本工作模式
Nginx的基本工作模式.jpg
一個master進程，生成一個或者多個worker進程。但是這里master是使用root身份啟動的，因為nginx要工作在80端口。而只有管理員才有權限啟動小于低于1023的端口。master主要是負責的作用只是啟動worker，加載配置文件，負責系統(tǒng)的平滑升級。其它的工作是交給worker。那么當worker被啟動之后，也只是負責一些web最簡單的工作，而其他的工作都是由worker中調(diào)用的模塊來實現(xiàn)的。 模塊之間是以流水線的方式實現(xiàn)功能的。流水線，指的是一個用戶請求，由多個模塊組合各自的功能依次實現(xiàn)完成的。比如：第一個模塊只負責分析請求首部，第二個模塊只負責查找數(shù)據(jù)，第三個模塊只負責壓縮數(shù)據(jù)，依次完成各自工作。來實現(xiàn)整個工作的完成。 他們是如何實現(xiàn)熱部署的呢？其實是這樣的，我們前面說master不負責具體的工作，而是調(diào)用worker工作，他只是負責讀取配置文件，因此當一個模塊修改或者配置文件發(fā)生變化，是由master進行讀取，因此此時不會影響到worker工作。在master進行讀取配置文件之后，不會立即把修改的配置文件告知worker。而是讓被修改的worker繼續(xù)使用老的配置文件工作，當worker工作完畢之后，直接殺死這個子進程，更換新的子進程，使用新的規(guī)則。
HAProxy也是使用較多的一款負載均衡軟件。HAProxy提供高可用性、負載均衡以及基于TCP和HTTP應用的代理，支持虛擬主機，是免費、快速并且可靠的一種解決方案。特別適用于那些負載特大的web站點。運行模式使得它可以很簡單安全的整合到當前的架構中，同時可以保護你的web服務器不被暴露到網(wǎng)絡上。 HAProxy是一個使用C語言編寫的自由及開放源代碼軟件，其提供高可用性、負載均衡，以及基于TCP和HTTP的應用程序代理。 Haproxy主要用來做七層負載均衡。
上面介紹負載均衡技術的時候提到過，負載均衡服務器在決定將請求轉發(fā)到具體哪臺真實服務器的時候，是通過負載均衡算法來實現(xiàn)的。負載均衡算法可以分為兩類：靜態(tài)負載均衡算法和動態(tài)負載均衡算法。
靜態(tài)負載均衡算法包括：輪詢，比率，優(yōu)先權
動態(tài)負載均衡算法包括: 最少連接數(shù),最快響應速度，觀察方法，預測法，動態(tài)性能分配，動態(tài)服務器補充，服務質(zhì)量，服務類型，規(guī)則模式。
輪詢（Round Robin）：順序循環(huán)將請求一次順序循環(huán)地連接每個服務器。當其中某個服務器發(fā)生第二到第7 層的故障，BIG-IP 就把其從順序循環(huán)隊列中拿出，不參加下一次的輪詢，直到其恢復正常。 以輪詢的方式依次請求調(diào)度不同的服務器； 實現(xiàn)時，一般為服務器帶上權重；這樣有兩個好處： 針對服務器的性能差異可分配不同的負載； 當需要將某個結點剔除時，只需要將其權重設置為0即可； 優(yōu)點：實現(xiàn)簡單、高效；易水平擴展； 缺點：請求到目的結點的不確定，造成其無法適用于有寫的場景（緩存，數(shù)據(jù)庫寫） 應用場景：數(shù)據(jù)庫或應用服務層中只有讀的場景； 隨機方式：請求隨機分布到各個結點；在數(shù)據(jù)足夠大的場景能達到一個均衡分布； 優(yōu)點：實現(xiàn)簡單、易水平擴展； 缺點：同Round Robin，無法用于有寫的場景； 應用場景：數(shù)據(jù)庫負載均衡，也是只有讀的場景；
哈希方式：根據(jù)key來計算需要落在的結點上，可以保證一個同一個鍵一定落在相同的服務器上； 優(yōu)點：相同key一定落在同一個結點上，這樣就可用于有寫有讀的緩存場景； 缺點：在某個結點故障后，會導致哈希鍵重新分布，造成命中率大幅度下降； 解決：一致性哈希 or 使用keepalived保證任何一個結點的高可用性，故障后會有其它結點頂上來； 應用場景：緩存，有讀有寫；
一致性哈希：在服務器一個結點出現(xiàn)故障時，受影響的只有這個結點上的key，最大程度的保證命中率； 如twemproxy中的ketama方案； 生產(chǎn)實現(xiàn)中還可以規(guī)劃指定子key哈希，從而保證局部相似特征的鍵能分布在同一個服務器上； 優(yōu)點：結點故障后命中率下降有限； 應用場景：緩存；
根據(jù)鍵的范圍來負載：根據(jù)鍵的范圍來負載，前1億個鍵都存放到第一個服務器，1~2億在第二個結點； 優(yōu)點：水平擴展容易，存儲不夠用時，加服務器存放后續(xù)新增數(shù)據(jù)； 缺點：負載不均；數(shù)據(jù)庫的分布不均衡；（數(shù)據(jù)有冷熱區(qū)分，一般最近注冊的用戶更加活躍，這樣造成后續(xù)的服務器非常繁忙，而前期的結點空閑很多） 適用場景：數(shù)據(jù)庫分片負載均衡；
根據(jù)鍵對服務器結點數(shù)取模來負載：根據(jù)鍵對服務器結點數(shù)取模來負載；比如有4臺服務器，key取模為0的落在第一個結點，1落在第二個結點上。 優(yōu)點：數(shù)據(jù)冷熱分布均衡，數(shù)據(jù)庫結點負載均衡分布； 缺點：水平擴展較難； 適用場景：數(shù)據(jù)庫分片負載均衡；
純動態(tài)結點負載均衡：根據(jù)CPU、IO、網(wǎng)絡的處理能力來決策接下來的請求如何調(diào)度； 優(yōu)點：充分利用服務器的資源，保證個結點上負載處理均衡； 缺點：實現(xiàn)起來復雜，真實使用較少；
不用主動負載均衡：使用消息隊列轉為異步模型，將負載均衡的問題消滅；負載均衡是一種推模型，一直向你發(fā)數(shù)據(jù)，那么，將所有的用戶請求發(fā)到消息隊列中，所有的下游結點誰空閑，誰上來取數(shù)據(jù)處理；轉為拉模型之后，消除了對下行結點負載的問題； 優(yōu)點：通過消息隊列的緩沖，保護后端系統(tǒng)，請求劇增時不會沖垮后端服務器； 水平擴展容易，加入新結點后，直接取queue即可； 缺點：不具有實時性； 應用場景：不需要實時返回的場景； 比如，12036下訂單后，立刻返回提示信息：您的訂單進去排隊了…等處理完畢后，再異步通知；
比率（Ratio）：給每個服務器分配一個加權值為比例，根椐這個比例，把用戶的請求分配到每個服務器。當其中某個服務器發(fā)生第二到第7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配, 直到其恢復正常。
優(yōu)先權（Priority）：給所有服務器分組,給每個組定義優(yōu)先權，BIG-IP 用戶的請求，分配給優(yōu)先級最高的服務器組（在同一組內(nèi)，采用輪詢或比率算法，分配用戶的請求）；當最高優(yōu)先級中所有服務器出現(xiàn)故障，BIG-IP 才將請求送給次優(yōu)先級的服務器組。這種方式，實際為用戶提供一種熱備份的方式。
最少的連接方式（Least Connection）：傳遞新的連接給那些進行最少連接處理的服務器。當其中某個服務器發(fā)生第二到第7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配, 直到其恢復正常。
最快模式（Fastest）：傳遞連接給那些響應最快的服務器。當其中某個服務器發(fā)生第二到第7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。
觀察模式（Observed）：連接數(shù)目和響應時間以這兩項的最佳平衡為依據(jù)為新的請求選擇服務器。當其中某個服務器發(fā)生第二到第7 層的故障，BIG-IP就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。
預測模式（Predictive）：BIG-IP利用收集到的服務器當前的性能指標，進行預測分析，選擇一臺服務器在下一個時間片內(nèi)，其性能將達到最佳的服務器相應用戶的請求。(被BIG-IP 進行檢測)
動態(tài)性能分配(Dynamic Ratio-APM):BIG-IP 收集到的應用程序和應用服務器的各項性能參數(shù)，動態(tài)調(diào)整流量分配。
動態(tài)服務器補充(Dynamic Server Act.):當主服務器群中因故障導致數(shù)量減少時，動態(tài)地將備份服務器補充至主服務器群。
服務質(zhì)量(QoS）:按不同的優(yōu)先級對數(shù)據(jù)流進行分配。
服務類型(ToS): 按不同的服務類型（在Type of Field中標識）負載均衡對數(shù)據(jù)流進行分配。
規(guī)則模式：針對不同的數(shù)據(jù)流設置導向規(guī)則，用戶可自行。
重慶分公司
重慶分公司
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)由於服務器上線和下線導致的並發(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);
}
}
/**
* 運行結果:
* 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 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)由於服務器上線和下線導致的並發(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);
/**
* 運行結果:
* 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)由於服務器上線和下線導致的並發(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);
}
/**
* 運行結果:
* 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);
}
/**
* 獲取請求服務器地址
* @param remoteIp 負載均衡服務器ip
* @return
*/
public static String ipHash(String remoteIp) {
// 重新建立一個map,避免出現(xiàn)由於服務器上線和下線導致的並發(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);
/**
* 運行結果:
* 192.168.1.18
*/
}
}看完上述內(nèi)容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝您對創(chuàng)新互聯(lián)的支持。
