負載均衡在分佈式架構中是怎麼玩起來的？

什麼是負載均衡（Load balancing）？

在網站創立初期，咱們通常都使用單臺機器對臺提供集中式服務，但隨着業務量愈來愈大，不管性能仍是穩定性上都有了更大的挑戰。這時候咱們就會想到經過擴容的方式來提供更好的服務。咱們通常會把多臺機器組成一個集羣對外提供服務。然而，咱們的網站對外提供的訪問入口都是一個的，好比www.taobao.com。那麼當用戶在瀏覽器輸入www.taobao.com的時候如何將用戶的請求分發到集羣中不一樣的機器上呢，這就是負載均衡在作的事情。

當前大多數的互聯網系統都使用了服務器集羣技術，集羣即將相同服務部署在多臺服務器上構成一個集羣總體對外提供服務，這些集羣能夠是Web應用服務器集羣，也能夠是數據庫服務器集羣，還能夠是分佈式緩存服務器集羣等。

在實際應用中，在Web服務器集羣以前總會有一臺負載均衡服務器，負載均衡設備的任務就是做爲Web服務器流量的入口，挑選最合適的一臺Web服務器，將客戶端的請求轉發給它處理，實現客戶端到真實服務端的透明轉發。最近幾年很火的「雲計算」以及分佈式架構，本質上也是將後端服務器做爲計算資源、存儲資源，由某臺管理服務器封裝成一個服務對外提供，客戶端不須要關心真正提供服務的是哪臺機器，在它看來，就好像它面對的是一臺擁有近乎無限能力的服務器，而本質上，真正提供服務的是後端的集羣。

軟件負載解決的兩個核心問題是：選誰、轉發，其中最著名的是LVS（Linux Virtual Server）。

 

 

 

一個典型的互聯網應用的拓撲結構是這樣的：

 

 

負載均衡分類

如今咱們知道，負載均衡就是一種計算機網絡技術，用來在多個計算機（計算機集羣）、網絡鏈接、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+四層負載+七層負載的方式進行多層次負載均衡。

 

 

 

經常使用負載均衡工具

硬件負載均衡性能優越，功能全面，但價格昂貴，通常適合初期或者土豪級公司長期使用。所以軟件負載均衡在互聯網領域大量使用。經常使用的軟件負載均衡軟件有Nginx、LVS、HaProxy等。

Nginx/LVS/HAProxy是目前使用最普遍的三種負載均衡軟件。

順便在此給你們推薦一個Java架構方面的交流學習羣：698581634，進羣便可獲取Java架構師資料：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系，羣裏必定有你須要的資料，你們趕忙加羣吧。

一、 LVS

LVS（Linux Virtual Server），也就是Linux虛擬服務器，是一個由章文嵩博士發起的自由軟件項目。使用LVS技術要達到的目標是：經過LVS提供的負載均衡技術和Linux操做系統實現一個高性能、高可用的服務器羣集，它具備良好可靠性、可擴展性和可操做性。從而以低廉的成本實現最優的服務性能。

LVS主要用來作四層負載均衡。

LVS架構

LVS架設的服務器集羣系統由三個部分組成：最前端的負載均衡層（Loader Balancer），中間的服務器羣組層，用Server Array表示，最底層的數據共享存儲層，用Shared Storage表示。在用戶看來全部的應用都是透明的，用戶只是在使用一個虛擬服務器提供的高性能服務。

 

 

 

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系列都能很好地支持。

二、Nginx

Nginx（發音同engine x）是一個網頁服務器，它能反向代理HTTP、HTTPS,、SMTP、POP三、IMAP的協議連接，以及一個負載均衡器和一個HTTP緩存。

Nginx主要用來作七層負載均衡。

併發性能：官方支持每秒5萬併發，實際國內通常到每秒2萬併發，有優化到每秒10萬併發的。具體性能看應用場景。

特色：

• 模塊化設計：良好的擴展性，能夠經過模塊方式進行功能擴展。
• 高可靠性：主控進程和worker是同步實現的，一個worker出現問題，會馬上啓動另外一個worker。
• 內存消耗低：一萬個長鏈接（keep-alive）,僅消耗2.5MB內存。
• 支持熱部署：不用中止服務器，實現更新配置文件，更換日誌文件、更新服務器程序版本。
• 併發能力強：官方數據每秒支持5萬併發；
• 功能豐富：優秀的反向代理功能和靈活的負載均衡策略

Nginx的基本工做模式

 

 

 

一個master進程，生成一個或者多個worker進程。但這裏master是使用root身份啓動的，由於nginx要工做在80端口。而只有管理員纔有權限啓動小於低於1023的端口。master主要是負責的做用只是啓動worker，加載配置文件，負責系統的平滑升級。其它的工做是交給worker。那當worker被啓動以後，也只是負責一些web最簡單的工做，而其它的工做都是由worker中調用的模塊來實現的。

模塊之間是以流水線的方式實現功能的。流水線，指的是一個用戶請求，由多個模塊組合各自的功能依次實現完成的。好比：第一個模塊只負責分析請求首部，第二個模塊只負責查找數據，第三個模塊只負責壓縮數據，依次完成各自工做。來實現整個工做的完成。

它們是如何實現熱部署的呢？是這樣的，咱們前面說master不負責具體的工做，而是調用worker工做，它只是負責讀取配置文件，所以當一個模塊修改或者配置文件發生變化，是由master進行讀取，所以此時不會影響到worker工做。在master進行讀取配置文件以後，不會當即把修改的配置文件告知worker。而是讓被修改的worker繼續使用老的配置文件工做，當worker工做完畢以後，直接當掉這個子進程，更換新的子進程，使用新的規則。

順便在此給你們推薦一個Java架構方面的交流學習羣：698581634，進羣便可獲取Java架構師資料：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系，羣裏必定有你須要的資料，你們趕忙加羣吧。

三、HAProxy

HAProxy也是使用較多的一款負載均衡軟件。HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支持虛擬主機，是免費、快速而且可靠的一種解決方案。特別適用於那些負載特大的web站點。運行模式使得它能夠很簡單安全的整合到當前的架構中，同時能夠保護你的web服務器不被暴露到網絡上。

HAProxy是一個使用C語言編寫的自由及開放源代碼軟件，其提供高可用性、負載均衡，以及基於TCP和HTTP的應用程序代理。

Haproxy主要用來作七層負載均衡。

常見負載均衡算法

上面介紹負載均衡技術的時候提到過，負載均衡服務器在決定將請求轉發到具體哪臺真實服務器時，是經過負載均衡算法來實現的。負載均衡算法能夠分爲兩類：靜態負載均衡算法和動態負載均衡算法。

• 靜態負載均衡算法包括：輪詢、比率、優先權。
• 動態負載均衡算法包括：最少鏈接數、最快響應速度、觀察方法、預測法、動態性能分配、動態服務器補充、服務質量、服務類型、規則模式。

輪詢（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）：給每一個服務器分配一個加權值爲比例，根椐這個比例，把用戶的請求分配到每一個服務器。當其中某個服務器發生第2到第7 層的故障，BIG-IP 就把其從服務器隊列中拿出，不參加下一次的用戶請求的分配，直到其恢復正常。

優先權（Priority）：給全部服務器分組，給每一個組定義優先權，BIG-IP 用戶的請求，分配給優先級最高的服務器組（在同一組內，採用輪詢或比率算法，分配用戶的請求）；當最高優先級中全部服務器出現故障，BIG-IP 纔將請求送給次優先級的服務器組。這種方式，實際爲用戶提供一種熱備份的方式。

最少的鏈接方式（Least Connection）：傳遞新的鏈接給那些進行最少鏈接處理的服務器。當其中某個服務器發生第2到第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實現代碼

• 輪詢
•  

 

•  
•  
• 加權隨機負載均衡算法
•  

 

•  
•  
• 隨機負載均衡算法
•  

 

•  
•  
• 負載均衡 ip_hash算法.
•  

原文連接：https://www.cnblogs.com/kingreatwill/p/7991151.html