• 首先它是基于4層的網(wǎng)絡(luò)協(xié)議的，僅作為分發(fā)只用，沒有流量的產(chǎn)生，抗負(fù)載能力強(qiáng)，對于服務(wù)器的硬件要求除了網(wǎng)卡外，其他沒有太多要求；
  

• 配置性比較低，這是一個缺點也是一個優(yōu)點，因為沒有可太多配置的東西，大大減少了人為出錯的幾率；

• 應(yīng)用范圍比較廣，不僅僅對web服務(wù)做負(fù)載均衡，還可以對其他應(yīng)用（mysql）做負(fù)載均衡；

• LVS架構(gòu)中存在一個虛擬IP的概念，需要向IDC多申請一個IP來做虛擬IP。

DR：直接路由模式

僅從性能上作比較：DR>TUN>NAT>FULLNAT

四種工作模式的詳細(xì)介紹：

• DR：直接路由模式
  

請求由 LVS 接受，由真實提供服務(wù)的服務(wù)器（RealServer, RS）直接返回給用戶，返回的時候不經(jīng)過 LVS。

DR 模式下需要 LVS 和綁定同一個 VIP（RS 通過將 VIP 綁定在 loopback 實現(xiàn)）。

一個請求過來時，LVS 只需要將網(wǎng)絡(luò)幀的 MAC 地址修改為某一臺 RS 的 MAC，該包就會被轉(zhuǎn)發(fā)到相應(yīng)的 RS 處理，注意此時的源 IP 和目標(biāo) IP 都沒變，LVS 只是做了一下移花接木。

RS 收到 LVS 轉(zhuǎn)發(fā)來的包，鏈路層發(fā)現(xiàn) MAC 是自己的，到上面的網(wǎng)絡(luò)層，發(fā)現(xiàn) IP 也是自己的，于是這個包被合法地接受，RS 感知不到前面有 LVS 的存在。

而當(dāng) RS 返回響應(yīng)時，只要直接向源 IP（即用戶的 IP）返回即可，不再經(jīng)過 LVS。

• TUN：隧道模式
  

客戶端將訪問vip報文發(fā)送給LVS服務(wù)器；

LVS服務(wù)器將請求報文重新封裝，發(fā)送給后端真實服務(wù)器；

后端真實服務(wù)器將請求報文解封，在確認(rèn)自身有vip之后進(jìn)行請求處理；

后端真實服務(wù)器在處理完數(shù)據(jù)請求后，直接響應(yīng)客戶端。

此模式實現(xiàn)起來較為復(fù)雜。

• NAT：路由轉(zhuǎn)發(fā)模式
  

NAT（Network Address Translation）是一種外網(wǎng)和內(nèi)網(wǎng)地址映射的技術(shù)。

多目標(biāo)的DNAT(iptables)轉(zhuǎn)換;它通過修改請求報文的目標(biāo)IP地址（同時可能會修改目標(biāo)端口)挑選出某Real Server的RIP地址實現(xiàn)轉(zhuǎn)發(fā)；在LVS負(fù)載均衡調(diào)度器上請求先發(fā)送給PREROUTING-->INPUT，然后經(jīng)由監(jiān)聽在INPUT上的LVS程序強(qiáng)制將請求轉(zhuǎn)發(fā)給 POSTROUTING

NAT 模式下，網(wǎng)絡(luò)報的進(jìn)出都要經(jīng)過 LVS 的處理。LVS 需要作為 RS 的網(wǎng)關(guān)。

當(dāng)包到達(dá) LVS 時，LVS 做目標(biāo)地址轉(zhuǎn)換（DNAT），將目標(biāo) IP 改為 RS 的 IP。RS 接收到包以后，仿佛是客戶端直接發(fā)給它的一樣。

RS 處理完，返回響應(yīng)時，源 IP 是 RS IP，目標(biāo) IP 是客戶端的 IP。

這時 RS 的包通過網(wǎng)關(guān)（LVS）中轉(zhuǎn)，LVS 會做源地址轉(zhuǎn)換（SNAT），將包的源地址改為 VIP，這樣，這個包對客戶端看起來就仿佛是 LVS 直接返回給它的。客戶端無法感知到后端 RS 的存在。

注意：

• FULLNAT模式
  

無論是 DR 還是 NAT 模式，不可避免的都有一個問題：LVS 和 RS 必須在同一個 VLAN 下，否則 LVS 無法作為 RS 的網(wǎng)關(guān)。

Full-NAT 相比 NAT 的主要改進(jìn)是，在 SNAT/DNAT 的基礎(chǔ)上，加上另一種轉(zhuǎn)換，轉(zhuǎn)換過程如下：

在包從 LVS 轉(zhuǎn)到 RS 的過程中，源地址從客戶端 IP 被替換成了 LVS 的內(nèi)網(wǎng) IP。

內(nèi)網(wǎng) IP 之間可以通過多個交換機(jī)跨 VLAN 通信。

當(dāng) RS 處理完接受到的包，返回時，會將這個包返回給 LVS 的內(nèi)網(wǎng) IP，這一步也不受限于 VLAN。

LVS 收到包后，在 NAT 模式修改源地址的基礎(chǔ)上，再把 RS 發(fā)來的包中的目標(biāo)地址從 LVS 內(nèi)網(wǎng) IP 改為客戶端的 IP。

Full-NAT 主要的思想是把網(wǎng)關(guān)和其下機(jī)器的通信，改為了普通的網(wǎng)絡(luò)通信，從而解決了跨 VLAN 的問題。采用這種方式，LVS 和 RS 的部署在 VLAN 上將不再有任何限制，大大提高了運(yùn)維部署的便利性。

均等地對待每一臺服務(wù)器，不管服務(wù)器上的實際連接數(shù)和系統(tǒng)負(fù)載

(2) 加權(quán)輪調(diào) wrr

調(diào)度器可以自動問詢真實服務(wù)器的負(fù)載情況，并動態(tài)調(diào)整權(quán)值

(3) 最少鏈接 lc

動態(tài)地將網(wǎng)絡(luò)請求調(diào)度到已建立的連接數(shù)最少的服務(wù)器上

如果集群真實的服務(wù)器具有相近的系統(tǒng)性能，采用該算法可以較好的實現(xiàn)負(fù)載均衡

(4) 加權(quán)最少鏈接 wlc

調(diào)度器可以自動問詢真實服務(wù)器的負(fù)載情況，并動態(tài)調(diào)整權(quán)值

帶權(quán)重的誰不干活就給誰分配，機(jī)器配置好的權(quán)重高

(5) 基于局部性的最少連接調(diào)度算法 lblc

這個算法是請求數(shù)據(jù)包的目標(biāo) IP 地址的一種調(diào)度算法，該算法先根據(jù)請求的目標(biāo) IP 地址尋找最近的該目標(biāo) IP 地址所有使用的服務(wù)器，如果這臺服務(wù)器依然可用，并且有能力處理該請求，調(diào)度器會盡量選擇相同的服務(wù)器，否則會繼續(xù)選擇其它可行的服務(wù)器

(6) 復(fù)雜的基于局部性最少的連接算法 lblcr

記錄的不是要給目標(biāo) IP 與一臺服務(wù)器之間的連接記錄，它會維護(hù)一個目標(biāo) IP 到一組服務(wù)器之間的映射關(guān)系，防止單點服務(wù)器負(fù)載過高。

(7) 目標(biāo)地址散列調(diào)度算法 dh

該算法是根據(jù)目標(biāo) IP 地址通過散列函數(shù)將目標(biāo) IP 與服務(wù)器建立映射關(guān)系，出現(xiàn)服務(wù)器不可用或負(fù)載過高的情況下，發(fā)往該目標(biāo) IP 的請求會固定發(fā)給該服務(wù)器。

(8) 源地址散列調(diào)度算法 sh

與目標(biāo)地址散列調(diào)度算法類似，但它是根據(jù)源地址散列算法進(jìn)行靜態(tài)分配固定的服務(wù)器資源。

(9) 最少期望延遲 sed

不考慮非活動鏈接，誰的權(quán)重大，優(yōu)先選擇權(quán)重大的服務(wù)器來接收請求，但權(quán)重大的機(jī)器會比較忙

(10) 永不排隊 nq

無需隊列，如果有realserver的連接數(shù)為0就直接分配過去

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

（1）HAProxy是支持虛擬主機(jī)的，通過frontend指令來實現(xiàn)

（2）支持Session的保持，Cookie的引導(dǎo)等工作

（3）支持url檢測后端的服務(wù)器出問題的檢測會有很好的幫助。

（4）它跟LVS一樣，本身僅僅就只是一款負(fù)載均衡軟件；單純從效率上來講HAProxy更會比Nginx有更出色的負(fù)載均衡速度，在并發(fā)處理上也是優(yōu)于Nginx的。

（5）HAProxy可以對Mysql讀進(jìn)行負(fù)載均衡，對后端的MySQL節(jié)點進(jìn)行檢測和負(fù)載均衡

HAProxy的負(fù)載調(diào)度算法

（1）roundrobin 表示簡單的輪詢

（2）static-rr 表示根據(jù)權(quán)重進(jìn)行輪詢

（3）leastconn 表示最少連接者先處理

（4）source 表示根據(jù)請求源IP，這個跟Nginx的IP_hash機(jī)制類似，我們用其作為解 決session問題的一種方法

（5）ri 表示根據(jù)請求的URI

（6）rl_param 表示根據(jù)請求的URl參數(shù)

（7）hdr(name) 表示根據(jù)HTTP請求頭來鎖定每一次HTTP請求

（8）rdp-cookie(name) 表示根據(jù)據(jù)cookie(name)來鎖定并哈希每一次TCP請求

HAProxy相比LVS的使用要簡單很多，功能方面也很豐富。當(dāng)前，HAProxy支持兩種主要的代理模式："tcp"也即4層（大多用于郵件服務(wù)器、內(nèi)部協(xié)議通信服務(wù)器等）、7層（HTTP）。在4層模式下，HAProxy僅在客戶端和服務(wù)器之間轉(zhuǎn)發(fā)雙向流量。7層模式下，HAProxy會分析協(xié)議，并且能通過允許、拒絕、交換、增加、修改或者請求(request)或者回應(yīng)(response)里指定內(nèi)容來控制協(xié)議，這種操作要基于特定規(guī)則。（新的1.3之后的版本引入了frontend,backend指令；frontend根據(jù)任意 HTTP請求頭內(nèi)容做規(guī)則匹配,然后把請求定向到相關(guān)的backend.）

以上是LVS和HAProxy的簡介及詳情，但上文只是陳述了它們的優(yōu)秀的地方，下面讓我們再來了解一下它們的不足，權(quán)衡利弊才能更好的幫我們進(jìn)行選擇。

1. LVS本身不支持正則表達(dá)式的處理，不能做動靜分離

2. 網(wǎng)站應(yīng)用比較龐大時，LVS實現(xiàn)起來比較復(fù)雜，特別是后端存在Windows Server的機(jī)器時

1. 不支持POP/SMTP協(xié)議

2. 不支持SPDY協(xié)議

3. 不支持HTTP cache功能

4. 重載配置的功能需要重啟進(jìn)程

5. 多進(jìn)程模式支持不夠友好

下圖是對二者進(jìn)行一個總結(jié)：

END

更多精彩干貨分享

點擊下方名片關(guān)注

IT那活兒