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

　　什麼是負載均衡（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是目前使用最廣泛的三種負載均衡軟體。

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

　　2、Nginx

　　Nginx（發音同engine x）是一個網頁伺服器，它能反向代理HTTP、HTTPS,、SMTP、POP3、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工作完畢之後，直接當掉這個子程式，更換新的子程式，使用新的規則。

　　3、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演算法.