一文讀懂負載均衡

最新 02-01

更多騰訊海量技術文章，請關注云加社區：https://cloud.tencent.com/developer/column

作者：雲+社區用戶

面對大量用戶訪問、高並發請求，海量數據，可以使用高性能的伺服器、大型資料庫，存儲設備，高性能Web伺服器，採用高效率的編程語言比如(Go,Scala)等，當單機容量達到極限時，我們需要考慮業務拆分和分散式部署，來解決大型網站訪問量大，並發量高，海量數據的問題。

從單機網站到分散式網站，很重要的區別是業務拆分和分散式部署，將應用拆分後，部署到不同的機器上，實現大規模分散式系統。分散式和業務拆分解決了，從集中到分布的問題，但是每個部署的獨立業務還存在單點的問題和訪問統一入口問題，為解決單點故障，我們可以採取冗餘的方式。將相同的應用部署到多台機器上。解決訪問統一入口問題，我們可以在集群前面增加負載均衡設備，實現流量分發。

負載均衡（Load Balance），意思是將負載（工作任務，訪問請求）進行平衡、分攤到多個操作單元（伺服器，組件）上進行執行。是解決高性能，單點故障（高可用），擴展性（水平伸縮）的終極解決方案。

一、負載均衡原理

系統的擴展可分為縱向（垂直）擴展和橫向（水平）擴展。縱向擴展，是從單機的角度通過增加硬體處理能力，比如CPU處理能力，內存容量，磁碟等方面，實現伺服器處理能力的提升，不能滿足大型分散式系統（網站），大流量，高並發，海量數據的問題。因此需要採用橫向擴展的方式，通過添加機器來滿足大型網站服務的處理能力。比如：一台機器不能滿足，則增加兩台或者多台機器，共同承擔訪問壓力。這就是典型的集群和負載均衡架構：如下圖：

應用集群：將同一應用部署到多台機器上，組成處理集群，接收負載均衡設備分發的請求，進行處理，並返回相應數據。

負載均衡設備：將用戶訪問的請求，根據負載均衡演算法，分發到集群中的一台處理伺服器。（一種把網路請求分散到一個伺服器集群中的可用伺服器上去的設備）

負載均衡的作用（解決的問題）：

1.解決並發壓力，提高應用處理性能（增加吞吐量，加強網路處理能力）；

2.提供故障轉移，實現高可用；

3.通過添加或減少伺服器數量，提供網站伸縮性（擴展性）；

4.安全防護；（負載均衡設備上做一些過濾，黑白名單等處理）

二、負載均衡分類

根據實現技術不同，可分為DNS負載均衡，HTTP負載均衡，IP負載均衡，鏈路層負載均衡等。

2.1DNS負載均衡

最早的負載均衡技術，利用域名解析實現負載均衡，在DNS伺服器，配置多個A記錄，這些A記錄對應的伺服器構成集群。大型網站總是部分使用DNS解析，作為第一級負載均衡。如下圖：

優點

使用簡單：負載均衡工作，交給DNS伺服器處理，省掉了負載均衡伺服器維護的麻煩

提高性能：可以支持基於地址的域名解析，解析成距離用戶最近的伺服器地址，可以加快訪問速度，改善性能；

缺點

可用性差：DNS解析是多級解析，新增/修改DNS後，解析時間較長；解析過程中，用戶訪問網站將失敗；

擴展性低：DNS負載均衡的控制權在域名商那裡，無法對其做更多的改善和擴展；

維護性差：也不能反映伺服器的當前運行狀態；支持的演算法少；不能區分伺服器的差異（不能根據系統與服務的狀態來判斷負載）

實踐建議

將DNS作為第一級負載均衡，A記錄對應著內部負載均衡的IP地址，通過內部負載均衡將請求分發到真實的Web伺服器上。一般用於互聯網公司，複雜的業務系統不合適使用。如下圖：

1.3 IP負載均衡

在網路層通過修改請求目標地址進行負載均衡。

用戶請求數據包，到達負載均衡伺服器後，負載均衡伺服器在操作系統內核進程獲取網路數據包，根據負載均衡演算法得到一台真實伺服器地址，然後將請求目的地址修改為，獲得的真實ip地址，不需要經過用戶進程處理。

真實伺服器處理完成後，響應數據包回到負載均衡伺服器，負載均衡伺服器，再將數據包源地址修改為自身的ip地址，發送給用戶瀏覽器。如下圖：

IP負載均衡，真實物理伺服器返回給負載均衡伺服器，存在兩種方式：（1）負載均衡伺服器在修改目的ip地址的同時修改源地址。將數據包源地址設為自身盤，即源地址轉換（snat）。（2）將負載均衡伺服器同時作為真實物理伺服器集群的網關伺服器。

優點：

（1）在內核進程完成數據分發，比在應用層分發性能更好；

缺點：

（2）所有請求響應都需要經過負載均衡伺服器，集群最大吞吐量受限於負載均衡伺服器網卡帶寬；

2.4鏈路層負載均衡

在通信協議的數據鏈路層修改mac地址，進行負載均衡。

數據分發時，不修改ip地址，指修改目標mac地址，配置真實物理伺服器集群所有機器虛擬ip和負載均衡伺服器ip地址一致，達到不修改數據包的源地址和目標地址，進行數據分發的目的。

實際處理伺服器ip和數據請求目的ip一致，不需要經過負載均衡伺服器進行地址轉換，可將響應數據包直接返回給用戶瀏覽器，避免負載均衡伺服器網卡帶寬成為瓶頸。也稱為直接路由模式（DR模式）。如下圖：

優點：性能好；

缺點：配置複雜；

實踐建議：DR模式是目前使用最廣泛的一種負載均衡方式。

2.5混合型負載均衡

由於多個伺服器群內硬體設備、各自的規模、提供的服務等的差異，可以考慮給每個伺服器群採用最合適的負載均衡方式，然後又在這多個伺服器群間再一次負載均衡或群集起來以一個整體向外界提供服務（即把這多個伺服器群當做一個新的伺服器群），從而達到最佳的性能。將這種方式稱之為混合型負載均衡。

此種方式有時也用於單台均衡設備的性能不能滿足大量連接請求的情況下。是目前大型互聯網公司，普遍使用的方式。

方式一，如下圖：

以上模式適合有動靜分離的場景，反向代理伺服器（集群）可以起到緩存和動態請求分發的作用，當時靜態資源緩存在代理伺服器時，則直接返回到瀏覽器。如果動態頁面則請求後面的應用負載均衡（應用集群）。

方式二，如下圖：

以上模式，適合動態請求場景。

因混合模式，可以根據具體場景，靈活搭配各種方式，以上兩種方式僅供參考。

三、負載均衡演算法

常用的負載均衡演算法有，輪詢，隨機，最少鏈接，源地址散列，加權等方式；

3.1 輪詢

將所有請求，依次分發到每台伺服器上，適合伺服器硬體同相同的場景。

優點：伺服器請求數目相同；

缺點：伺服器壓力不一樣，不適合伺服器配置不同的情況；

3.2 隨機

請求隨機分配到各個伺服器。優點：使用簡單；

缺點：不適合機器配置不同的場景；

3.3 最少鏈接

將請求分配到連接數最少的伺服器（目前處理請求最少的伺服器）。

優點：根據伺服器當前的請求處理情況，動態分配；

缺點：演算法實現相對複雜，需要監控伺服器請求連接數；

3.4 Hash（源地址散列）

根據IP地址進行Hash計算，得到IP地址。

優點：將來自同一IP地址的請求，同一會話期內，轉發到相同的伺服器；實現會話粘滯。

缺點：目標伺服器宕機後，會話會丟失；

3.5 加權

在輪詢，隨機，最少鏈接，Hash』等演算法的基礎上，通過加權的方式，進行負載伺服器分配。

優點：根據權重，調節轉發伺服器的請求數目；

缺點：使用相對複雜；

四、硬體負載均衡

採用硬體的方式實現負載均衡，一般是單獨的負載均衡伺服器，價格昂貴，一般土豪級公司可以考慮，業界領先的有兩款，F5和A10。

使用硬體負載均衡，主要考慮一下幾個方面：

（1）功能考慮：功能全面支持各層級的負載均衡，支持全面的負載均衡演算法，支持全局負載均衡；

（2）性能考慮：一般軟體負載均衡支持到5萬級並發已經很困難了，硬體負載均衡可以支持

（3）穩定性：商用硬體負載均衡，經過了良好的嚴格的測試，從經過大規模使用，在穩定性方面高；

（4）安全防護：硬體均衡設備除具備負載均衡功能外，還具備防火牆，防DDOS攻擊等安全功能；

（5）維護角度：提供良好的維護管理界面，售後服務和技術支持；

（6）土豪公司：F5 Big Ip 價格：15w~55w不等；A10 價格：55w-100w不等；

缺點

（1）價格昂貴；

（2）擴展能力差；

4.4小結

（1）一般硬體的負載均衡也要做雙機高可用，因此成本會比較高。

（2）互聯網公司一般使用開源軟體，因此大部分應用採用軟體負載均衡；部分採用硬體負載均衡。

比如某互聯網公司，目前是使用幾台F5做全局負載均衡，內部使用Nginx等軟體負載均衡。

二、Ngnix負載均衡

Ngnix是一款輕量級的Web伺服器/反向代理伺服器，工作在七層Http協議的負載均衡系統。具有高性能、高並發、低內存使用等特點。是一個輕量級的Http和反向代理伺服器。Nginx使用epoll and kqueue作為開發模型。能夠支持高達 50,000 個並發連接數的響應。

操作系統：Liunx，Windows（Linux、FreeBSD、Solaris、Mac OS X、AIX以及Microsoft Windows）

開發語言：C

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

2.1.特點

1.模塊化設計：良好的擴展性，可以通過模塊方式進行功能擴展。

2.高可靠性：主控進程和worker是同步實現的，一個worker出現問題，會立刻啟動另一個worker。

3.內存消耗低：一萬個長連接（keep-alive）,僅消耗2.5MB內存。

4.支持熱部署：不用停止伺服器，實現更新配置文件，更換日誌文件、更新伺服器程序版本。

5.並發能力強：官方數據每秒支持5萬並發；

6.功能豐富：優秀的反向代理功能和靈活的負載均衡策略

2.2.功能

2.2.1基本功能

支持靜態資源的web伺服器。

http,smtp,pop3協議的反向代理伺服器、緩存、負載均衡；

支持FASTCGI（fpm）

支持模塊化，過濾器（讓文本可以實現壓縮，節約帶寬）,ssl及圖像大小調整。

內置的健康檢查功能

基於名稱和ip的虛擬主機

定製訪問日誌

支持平滑升級

支持KEEPALIVE

支持url rewrite

支持路徑別名

支持基於IP和用戶名的訪問控制。

支持傳輸速率限制，支持並發數限制。

2.2.2擴展功能

2.2.3性能

Nginx的高並發，官方測試支持5萬並發連接。實際生產環境能到2-3萬並發連接數。10000個非活躍的HTTP keep-alive 連接僅佔用約2.5MB內存。三萬並發連接下，10個Nginx進程，消耗內存150M。淘寶tengine團隊測試結果是「24G內存機器上，處理並發請求可達200萬」。

2.3架構

2.3.1Nginx的基本工作模式

一個master進程，生成一個或者多個worker進程。但是這裡master是使用root身份啟動的，因為nginx要工作在80埠。而只有管理員才有許可權啟動小於低於1023的埠。master主要是負責的作用只是啟動worker，載入配置文件，負責系統的平滑升級。其它的工作是交給worker。那麼當worker被啟動之後，也只是負責一些web最簡單的工作，而其他的工作都是有worker中調用的模塊來實現的。

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

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

2.3.2Nginx支持的sendfile機制

Sendfile機制，用戶將請求發給內核，內核根據用戶的請求調用相應用戶進程，進程在處理時需要資源。此時再把請求發給內核（進程沒有直接IO的能力），由內核載入數據。內核查找到數據之後，會把數據複製給用戶進程，由用戶進程對數據進行封裝，之後交給內核，內核在進行tcp/ip首部的封裝，最後再發給客戶端。這個功能用戶進程只是發生了一個封裝報文的過程，卻要繞一大圈。因此nginx引入了sendfile機制，使得內核在接受到數據之後，不再依靠用戶進程給予封裝，而是自己查找自己封裝，減少了一個很長一段時間的浪費，這是一個提升性能的核心點。

以上內容摘自網友發布的文章，簡單一句話是資源的處理，直接通過內核層進行數據傳遞，避免了數據傳遞到應用層，應用層再傳遞到內核層的開銷。

目前高並發的處理，一般都採用sendfile模式。通過直接操作內核層數據，減少應用與內核層數據傳遞。

2.3.3Nginx通信模型（I/O復用機制）

開發模型：epoll和kqueue。

支持的事件機制：kqueue、epoll、rt signals、/dev/poll 、event ports、select以及poll。

支持的kqueue特性包括EV_CLEAR、EV_DISABLE、NOTE_LOWAT、EV_EOF，可用數據的數量，錯誤代碼.

支持sendfile、sendfile64和sendfilev;文件AIO；DIRECTIO;支持Accept-filters和TCP_DEFER_ACCEP.

以上概念較多，大家自行百度或谷歌，知識領域是網路通信（BIO,NIO,AIO）和多線程方面的知識。

2.4均衡策略

nginx的負載均衡策略可以劃分為兩大類：內置策略和擴展策略。內置策略包含加權輪詢和ip hash，在默認情況下這兩種策略會編譯進nginx內核，只需在nginx配置中指明參數即可。擴展策略有很多，如fair、通用hash、consistent hash等，默認不編譯進nginx內核。由於在nginx版本升級中負載均衡的代碼沒有本質性的變化，因此下面將以nginx1.0.15穩定版為例，從源碼角度分析各個策略。

2.4.1. 加權輪詢（weighted round robin）

輪詢的原理很簡單，首先我們介紹一下輪詢的基本流程。如下是處理一次請求的流程圖：

圖中有兩點需要注意，第一，如果可以把加權輪詢演算法分為先深搜索和先廣搜索，那麼nginx採用的是先深搜索演算法，即將首先將請求都分給高權重的機器，直到該機器的權值降到了比其他機器低，才開始將請求分給下一個高權重的機器；第二，當所有後端機器都down掉時，nginx會立即將所有機器的標誌位清成初始狀態，以避免造成所有的機器都處在timeout的狀態，從而導致整個前端被夯住。

2.4.2. ip hash

ip hash是nginx內置的另一個負載均衡的策略，流程和輪詢很類似，只是其中的演算法和具體的策略有些變化，如下圖所示：

2.4.3. fair

fair策略是擴展策略，默認不被編譯進nginx內核。其原理是根據後端伺服器的響應時間判斷負載情況，從中選出負載最輕的機器進行分流。這種策略具有很強的自適應性，但是實際的網路環境往往不是那麼簡單，因此要慎用。

2.4.4 通用hash、一致性hash

這兩種也是擴展策略，在具體的實現上有些差別，通用hash比較簡單，可以以nginx內置的變數為key進行hash，一致性hash採用了nginx內置的一致性hash環，可以支持memcache。

2.5場景

Ngnix一般作為入口負載均衡或內部負載均衡，結合反向代理伺服器使用。以下架構示例，僅供參考，具體使用根據場景而定。

2.5.1入口負載均衡架構

Ngnix伺服器在用戶訪問的最前端。根據用戶請求再轉發到具體的應用伺服器或二級負載均衡伺服器（LVS）

2.5.2內部負載均衡架構

LVS作為入口負載均衡，將請求轉發到二級Ngnix伺服器，Ngnix再根據請求轉發到具體的應用伺服器。

2.5.3Ngnix高可用

分散式系統中，應用只部署一台伺服器會存在單點故障，負載均衡同樣有類似的問題。一般可採用主備或負載均衡設備集群的方式節約單點故障或高並發請求分流。

Ngnix高可用，至少包含兩個Ngnix伺服器，一台主伺服器，一台備伺服器，之間使用Keepalived做健康監控和故障檢測。開放VIP埠，通過防火牆進行外部映射。

DNS解析公網的IP實際為VIP。

三、LVS負載均衡

LVS是一個開源的軟體，由畢業於國防科技大學的章文嵩博士於1998年5月創立，用來實現Linux平台下的簡單負載均衡。LVS是Linux Virtual Server的縮寫，意思是Linux虛擬伺服器。

基於IP層的負載均衡調度技術，它在操作系統核心層上，將來自IP層的TCP/UDP請求均衡地轉移到不同的伺服器，從而將一組伺服器構成一個高性能、高可用的虛擬伺服器。

操作系統：Liunx

開發語言：C

並發性能：默認4096，可以修改但需要重新編譯。

3.1.功能

LVS的主要功能是實現IP層（網路層）負載均衡，有NAT,TUN,DR三種請求轉發模式。

3.1.1LVS/NAT方式的負載均衡集群

NAT是指Network Address Translation，它的轉發流程是：Director機器收到外界請求，改寫數據包的目標地址，按相應的調度演算法將其發送到相應Real Server上，Real Server處理完該請求後，將結果數據包返回到其默認網關，即Director機器上，Director機器再改寫數據包的源地址，最後將其返回給外界。這樣就完成一次負載調度。

構架一個最簡單的LVS/NAT方式的負載均衡集群Real Server可以是任何的操作系統，而且無需做任何特殊的設定，惟一要做的就是將其默認網關指向Director機器。Real Server可以使用區域網的內部IP(192.168.0.0/24)。Director要有兩塊網卡，一塊網卡綁定一個外部IP地址 (10.0.0.1)，另一塊網卡綁定區域網的內部IP(192.168.0.254)，作為Real Server的默認網關。

LVS/NAT方式實現起來最為簡單，而且Real Server使用的是內部IP，可以節省Real IP的開銷。但因為執行NAT需要重寫流經Director的數據包，在速度上有一定延遲；

當用戶的請求非常短，而伺服器的回應非常大的情況下，會對Director形成很大壓力，成為新的瓶頸，從而使整個系統的性能受到限制。

3.1.2LVS/TUN方式的負載均衡集群

TUN是指IP Tunneling，它的轉發流程是：Director機器收到外界請求，按相應的調度演算法,通過IP隧道發送到相應Real Server，Real Server處理完該請求後，將結果數據包直接返回給客戶。至此完成一次負載調度。

最簡單的LVS/TUN方式的負載均衡集群架構使用IP Tunneling技術，在Director機器和Real Server機器之間架設一個IP Tunnel，通過IP Tunnel將負載分配到Real Server機器上。Director和Real Server之間的關係比較鬆散，可以是在同一個網路中，也可以是在不同的網路中，只要兩者能夠通過IP Tunnel相連就行。收到負載分配的Real Server機器處理完後會直接將反饋數據送回給客戶，而不必通過Director機器。實際應用中，伺服器必須擁有正式的IP地址用於與客戶機直接通信，並且所有伺服器必須支持IP隧道協議。

該方式中Director將客戶請求分配到不同的Real Server，Real Server處理請求後直接回應給用戶，這樣Director就只處理客戶機與伺服器的一半連接，極大地提高了Director的調度處理能力，使集群系統能容納更多的節點數。另外TUN方式中的Real Server可以在任何LAN或WAN上運行，這樣可以構築跨地域的集群，其應對災難的能力也更強，但是伺服器需要為IP封裝付出一定的資源開銷，而且後端的Real Server必須是支持IP Tunneling的操作系統。

3.3.3LVS/TUN方式的負載均衡集群

DR是指Direct Routing，它的轉發流程是：Director機器收到外界請求，按相應的調度演算法將其直接發送到相應Real Server，Real Server處理完該請求後，將結果數據包直接返回給客戶，完成一次負載調度。

構架一個最簡單的LVS/DR方式的負載均衡集群Real Server和Director都在同一個物理網段中，Director的網卡IP是192.168.0.253，再綁定另一個IP： 192.168.0.254作為對外界的virtual IP，外界客戶通過該IP來訪問整個集群系統。Real Server在lo上綁定IP：192.168.0.254，同時加入相應的路由。

LVS/DR方式與前面的LVS/TUN方式有些類似，前台的Director機器也是只需要接收和調度外界的請求，而不需要負責返回這些請求的反饋結果，所以能夠負載更多的Real Server，提高Director的調度處理能力，使集群系統容納更多的Real Server。但LVS/DR需要改寫請求報文的MAC地址，所以所有伺服器必須在同一物理網段內。

3.3架構

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

LVS的體系架構如圖：

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.4均衡策略

LVS默認支持八種負載均衡策略，簡述如下：

3.4.1.輪詢調度（Round Robin）

調度器通過「輪詢」調度演算法將外部請求按順序輪流分配到集群中的真實伺服器上，它均等地對待每一台伺服器，而不管伺服器上實際的連接數和系統負載。

3.4.2.加權輪詢（Weighted Round Robin）

調度器通過「加權輪詢」調度演算法根據真實伺服器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的伺服器能處理更多的訪問流量。調度器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。

3.4.3.最少鏈接（Least Connections）

調度器通過「最少連接」調度演算法動態地將網路請求調度到已建立的鏈接數最少的伺服器上。如果集群系統的真實伺服器具有相近的系統性能，採用「最小連接」調度演算法可以較好地均衡負載。

3.4.4.加權最少鏈接（Weighted Least Connections）

在集群系統中的伺服器性能差異較大的情況下，調度器採用「加權最少鏈接」調度演算法優化負載均衡性能，具有較高權值的伺服器將承受較大比例的活動連接負載。調度器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。

3.4.5.基於局部性的最少鏈接（Locality-Based Least Connections）

「基於局部性的最少鏈接」調度演算法是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。該演算法根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器是可用的且沒有超載，將請求發送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處於一半的工作負載，則用「最少鏈接」的原則選出一個可用的伺服器，將請求發送到該伺服器。

3.4.6.帶複製的基於局部性最少鏈接（Locality-Based Least Connections with Replication）

「帶複製的基於局部性最少鏈接」調度演算法也是針對目標IP地址的負載均衡，目前主要用於Cache集群系統。它與LBLC演算法的不同之處是它要維護從一個目標IP地址到一組伺服器的映射，而LBLC演算法維護從一個目標IP地址到一台伺服器的映射。該演算法根據請求的目標IP地址找出該目標IP地址對應的伺服器組，按「最小連接」原則從伺服器組中選出一台伺服器，若伺服器沒有超載，將請求發送到該伺服器；若伺服器超載，則按「最小連接」原則從這個集群中選出一台伺服器，將該伺服器加入到伺服器組中，將請求發送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低複製的程度。

3.4.7.目標地址散列（Destination Hashing）

「目標地址散列」調度演算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。

3.4.8.源地址散列（Source Hashing）

「源地址散列」調度演算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的伺服器，若該伺服器是可用的且未超載，將請求發送到該伺服器，否則返回空。

除具備以上負載均衡演算法外，還可以自定義均衡策略。

3.5場景

一般作為入口負載均衡或內部負載均衡，結合反向代理伺服器使用。相關架構可參考Ngnix場景架構。

4、HaProxy負載均衡

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

4.1.特點

支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機；

配置簡單，支持url檢測後端伺服器狀態；

做負載均衡軟體使用，在高並發情況下，處理速度高於nginx；

TCP層多用於Mysql從（讀）伺服器負載均衡。（對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡）

能夠補充Nginx的一些缺點比如Session的保持，Cookie引導等工作

4.2.均衡策略

支持四種常用演算法：

1.roundrobin：輪詢，輪流分配到後端伺服器；

2.static-rr：根據後端伺服器性能分配；

3.leastconn：最小連接者優先處理；

4.source：根據請求源IP，與Nginx的IP_Hash類似。