一、LVS

1、簡介

LVS 是 Linux Virtual Server 的簡稱，也就是 Linux 虛擬服務(wù)器。
現(xiàn)在 LVS 已經(jīng)是 Linux 標(biāo)準(zhǔn)內(nèi)核的一部分，從 Linux2.4 內(nèi)核以后，已經(jīng)完全內(nèi)置了 LVS 的各個功能模塊，無需給內(nèi)核打任何補(bǔ)丁，可以直接使用 LVS 提供的各種功能。

LVS 不像 HAProxy 等七層軟負(fù)載面向的是 HTTP 包，所以七層負(fù)載可以做的 URL 解析等工作，LVS 無法完成。
LVS 是四層負(fù)載均衡，也就是說建立在 OSI 模型的第四層——傳輸層之上，傳輸層上有我們熟悉的 TCP/UDP，LVS 支持 TCP/UDP 的負(fù)載均衡。因?yàn)?LVS 是四層負(fù)載均衡，因此它相對于其它高層負(fù)載均衡的解決辦法，比如 DNS 域名輪流解析、應(yīng)用層負(fù)載的調(diào)度、客戶端的調(diào)度等，它的效率是非常高的。

所謂四層負(fù)載均衡 ，也就是主要通過報文中的目標(biāo)地址和端口。
七層負(fù)載均衡 ，也稱為“內(nèi)容交換”，也就是主要通過報文中的真正有意義的應(yīng)用層內(nèi)容。
LVS 的轉(zhuǎn)發(fā)主要通過修改 IP 地址（NAT 模式，分為源地址修改 SNAT 和目標(biāo)地址修改 DNAT）、修改目標(biāo) MAC（DR 模式）來實(shí)現(xiàn)。

2、NAT 模式：網(wǎng)絡(luò)地址轉(zhuǎn)換

NAT（Network Address Translation）是一種外網(wǎng)和內(nèi)網(wǎng)地址映射的技術(shù)。
NAT 模式下，網(wǎng)絡(luò)數(shù)據(jù)報的進(jìn)出都要經(jīng)過 LVS 的處理。LVS 需要作為 RS（真實(shí)服務(wù)器）的網(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 直接返回給它的。

3、DR 模式：直接路由

DR 模式下需要 LVS 和 RS 集群綁定同一個 VIP（RS 通過將 VIP 綁定在 loopback 實(shí)現(xiàn)），
但與 NAT 的不同點(diǎn)在于：請求由 LVS 接受，由真實(shí)提供服務(wù)的服務(wù)器（RealServer，RS）直接返回給用戶，返回的時候不經(jīng)過 LVS。

仔細(xì)來說，一個請求過來時，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。

4、LVS優(yōu)缺點(diǎn)

1、抗負(fù)載能力強(qiáng)?？关?fù)載能力強(qiáng)、性能高，能達(dá)到F5硬件的60%；對內(nèi)存和cpu資源消耗比較低
2、工作在網(wǎng)絡(luò)4層，通過vrrp協(xié)議轉(zhuǎn)發(fā)（僅作分發(fā)之用），具體的流量由linux內(nèi)核處理，因此沒有流量的產(chǎn)生。
3、應(yīng)用范圍比較廣，可以對所有應(yīng)用做負(fù)載均衡；
4、不支持正則處理，不能做動靜分離。
5、支持負(fù)載均衡算法：rr（輪循）、wrr（帶權(quán)輪循）、lc（最小連接）、wlc（權(quán)重最小連接）
6、配置 復(fù)雜，對網(wǎng)絡(luò)依賴比較大，穩(wěn)定性很高。
7、穩(wěn)定性、可靠性好，自身有完美的熱備方案；（如：LVS+Keepalived）

二、Nginx

1、簡介

Nginx 是一個強(qiáng)大的 Web 服務(wù)器軟件，用于處理高并發(fā)的 HTTP 請求和作為反向代理服務(wù)器做負(fù)載均衡。
具有高性能、輕量級、內(nèi)存消耗少，強(qiáng)大的負(fù)載均衡能力等優(yōu)勢。

相對于傳統(tǒng)基于進(jìn)程或線程的模型（Apache就采用這種模型）在處理并發(fā)連接時會為每一個連接建立一個單獨(dú)的進(jìn)程或線程，且在網(wǎng)絡(luò)或者輸入/輸出操作時阻塞。這將導(dǎo)致內(nèi)存和 CPU 的大量消耗，因?yàn)樾缕鹨粋€單獨(dú)的進(jìn)程或線程需要準(zhǔn)備新的運(yùn)行時環(huán)境，包括堆和棧內(nèi)存的分配，以及新的執(zhí)行上下文，當(dāng)然，這些也會導(dǎo)致多余的 CPU 開銷。最終，會由于過多的上下文切換而導(dǎo)致服務(wù)器性能變差。

Nginx 的架構(gòu)設(shè)計是采用模塊化的、基于事件驅(qū)動、異步、單線程且非阻塞。
Nginx 大量使用多路復(fù)用和事件通知，Nginx 啟動以后，會在系統(tǒng)中以 daemon 的方式在后臺運(yùn)行，其中包括一個 master 進(jìn)程，n(n>=1) 個 worker 進(jìn)程。所有的進(jìn)程都是單線程（即只有一個主線程）的，且進(jìn)程間通信主要使用共享內(nèi)存的方式。

其中master 進(jìn)程用于接收來自外界的信號，并給 worker 進(jìn)程發(fā)送信號，同時監(jiān)控 worker 進(jìn)程的工作狀態(tài)。worker 進(jìn)程則是外部請求真正的處理者，每個 worker 請求相互獨(dú)立且平等的競爭來自客戶端的請求。請求只能在一個 worker 進(jìn)程中被處理，且一個 worker 進(jìn)程只有一個主線程，所以同時只能處理一個請求

2、Nginx 負(fù)載均衡

Nginx 負(fù)載均衡主要是對七層網(wǎng)絡(luò)通信模型中的第七層應(yīng)用層上的 http、https 進(jìn)行支持。
Nginx 是以反向代理的方式進(jìn)行負(fù)載均衡的。反向代理（Reverse Proxy）方式是指以代理服務(wù)器來接受 Internet 上的連接請求，然后將請求轉(zhuǎn)發(fā)給內(nèi)部網(wǎng)絡(luò)上的服務(wù)器，并將從服務(wù)器上得到的結(jié)果返回給 Internet 上請求連接的客戶端，此時代理服務(wù)器對外就表現(xiàn)為一個服務(wù)器。

Nginx 實(shí)現(xiàn)負(fù)載均衡的分配策略有很多，Nginx 的 upstream 目前支持以下幾種方式：
  輪詢（默認(rèn)）：每個請求按時間順序逐一分配到不同的后端服務(wù)器，如果后端服務(wù)器 down 掉，能自動剔除。
  weight：指定輪詢幾率，weight 和訪問比率成正比，用于后端服務(wù)器性能不均的情況。
  ip_hash：每個請求按訪問 ip 的 hash 結(jié)果分配，這樣每個訪客固定訪問一個后端服務(wù)器，可以解決 session 的問題。
  fair（第三方）：按后端服務(wù)器的響應(yīng)時間來分配請求，響應(yīng)時間短的優(yōu)先分配。
  url_hash（第三方）：按訪問 url 的 hash 結(jié)果來分配請求，使每個 url 定向到同一個后端服務(wù)器，后端服務(wù)器為緩存時比較有效。

3、Ngnix優(yōu)缺點(diǎn)

1、工作在網(wǎng)絡(luò)的7層之上，可以針對http應(yīng)用做一些分流的策略，比如針對域名、目錄結(jié)構(gòu)；
2、Nginx對網(wǎng)絡(luò)的依賴比較小，理論上能ping通就就能進(jìn)行負(fù)載功能；
3、Nginx安裝和配置比較簡單，測試起來比較方便；
4、內(nèi)存消耗?。禾幚泶蟛l(fā)的請求內(nèi)存消耗非常小。在3萬并發(fā)連接下，開啟的10個 Nginx 進(jìn)程才消耗150M 內(nèi)存（15M*10=150M）；
5、對后端服務(wù)器的健康檢查，只支持通過端口來檢測，不支持通過url來檢測。
6、Nginx對請求的異步處理可以幫助節(jié)點(diǎn)服務(wù)器減輕負(fù)載；
7、Nginx僅能支持http、https和Email協(xié)議，這樣就在適用范圍較小。
8、不支持Session的直接保持，但能通過ip_hash來解決。、對Big request header的支持不是很好，
9、支持負(fù)載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權(quán)輪循）、Ip-hash（Ip哈希）
10、Nginx還能做Web服務(wù)器即Cache功能。

三、HAProxy

1、簡介

HAProxy提供高可用性、負(fù)載均衡以及基于TCP和HTTP應(yīng)用的代理，支持虛擬主機(jī)，它是免費(fèi)、快速并且可靠的一種解決方案。HAProxy特別適用于那些負(fù)載特大的web站點(diǎn)，這些站點(diǎn)通常又需要會話保持或七層處理。HAProxy運(yùn)行在當(dāng)前的硬件上，完全可以支持?jǐn)?shù)以萬計的并發(fā)連接。并且它的運(yùn)行模式使得它可以很簡單安全的整合進(jìn)您當(dāng)前的架構(gòu)中， 同時可以保護(hù)你的web服務(wù)器不被暴露到網(wǎng)絡(luò)上。
HAProxy實(shí)現(xiàn)了一種事件驅(qū)動, 單一進(jìn)程模型，此模型支持非常大的并發(fā)連接數(shù)。多進(jìn)程或多線程模型受內(nèi)存限制 、系統(tǒng)調(diào)度器限制以及無處不在的鎖限制，很少能處理數(shù)千并發(fā)連接。事件驅(qū)動模型因?yàn)樵谟懈玫馁Y源和時間管理的用戶空間(User-Space) 實(shí)現(xiàn)所有這

2、負(fù)載平衡的類型

1）無負(fù)載平衡：沒有負(fù)載平衡的簡單Web應(yīng)用程序環(huán)境

用戶直接連接到您的Web服務(wù)器，在yourdomain.com上，并且沒有負(fù)載平衡。如果您的單個Web服務(wù)器出現(xiàn)故障，用戶將無法再訪問您的Web服務(wù)器。此外，如果許多用戶試圖同時訪問您的服務(wù)器并且無法處理負(fù)載，他們可能會遇到緩慢的體驗(yàn)，或者可能根本無法連接。

2）4層負(fù)載平衡：

將網(wǎng)絡(luò)流量負(fù)載平衡到多個服務(wù)器的最簡單方法是使用第4層（傳輸層）負(fù)載平衡。以這種方式進(jìn)行負(fù)載均衡將根據(jù)IP范圍和端口轉(zhuǎn)發(fā)用戶流量（即，如果請求進(jìn)入http://yourdomain.com/anything，則流量將轉(zhuǎn)發(fā)到處理yourdomain.com的所有請求的后端。端口80）。

用戶訪問負(fù)載均衡器，負(fù)載均衡器將用戶的請求轉(zhuǎn)發(fā)給后端服務(wù)器的Web后端組。無論選擇哪個后端服務(wù)器，都將直接響應(yīng)用戶的請求。通常，Web后端中的所有服務(wù)器應(yīng)該提供相同的內(nèi)容 - 否則用戶可能會收到不一致的內(nèi)容。

3）7層負(fù)載平衡：

7層負(fù)載平衡是更復(fù)雜的負(fù)載均衡網(wǎng)絡(luò)流量的方法是使用第7層（應(yīng)用層）負(fù)載均衡。使用第7層允許負(fù)載均衡器根據(jù)用戶請求的內(nèi)容將請求轉(zhuǎn)發(fā)到不同的后端服務(wù)器。這種負(fù)載平衡模式允許您在同一域和端口下運(yùn)行多個Web應(yīng)用程序服務(wù)器。

如果用戶請求yourdomain.com/blog，則會將其轉(zhuǎn)發(fā)到博客后端，后端是一組運(yùn)行博客應(yīng)用程序的服務(wù)器。其他請求被轉(zhuǎn)發(fā)到web-backend，后端可能正在運(yùn)行另一個應(yīng)用程序。

3、HAProxy優(yōu)缺點(diǎn)

1、HAProxy 支持兩種代理模式 TCP（四層）和HTTP（七層），也是支持虛擬主機(jī)的。
2、HAProxy 的優(yōu)點(diǎn)能夠補(bǔ)充 Nginx 的一些缺點(diǎn)，比如支持 Session 的保持，Cookie 的引導(dǎo)；同時支持通過獲取指定的 url 來檢測后端服務(wù)器的狀態(tài)。
3、HAProxy 跟 LVS 類似，本身就只是一款負(fù)載均衡軟件；單純從效率上來講 HAProxy 會比 Nginx 有更出色的負(fù)載均衡速度，在并發(fā)處理上也是優(yōu)于 Nginx 的。
4、HAProxy 支持 TCP 協(xié)議的負(fù)載均衡轉(zhuǎn)發(fā)，可以對 MySQL 讀進(jìn)行負(fù)載均衡，對后端的 MySQL 節(jié)點(diǎn)進(jìn)行檢測和負(fù)載均衡，大家可以用 LVS+Keepalived 對 MySQL 主從做負(fù)載均衡。
5、支持url檢測后端的服務(wù)器出問題的檢測會有很好的幫助。
6、HAProxy 負(fù)載均衡策略非常多：Round-robin（輪循）、Weight-round-robin（帶權(quán)輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據(jù)cookie）.更多的負(fù)載均衡策略比如：動態(tài)加權(quán)輪循(Dynamic Round Robin)，加權(quán)源地址哈希(Weighted Source Hash)，加權(quán)URL哈希和加權(quán)參數(shù)哈希(Weighted Parameter Hash)已經(jīng)實(shí)現(xiàn)
7、不能做Web服務(wù)器即Cache。
8、根據(jù)官方文檔，HAProxy可以跑滿10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom's 10GbE NICs (Myri-10G PCI-Express)，這個作為軟件級負(fù)載均衡，也是比較驚人的；
9、HAProxy支持虛擬主機(jī)
10、經(jīng)過官方測試統(tǒng)計，haproxy 單位時間處理的最大請求數(shù)為20000個，可以同時維護(hù)40000-50000個并發(fā)連接，最大數(shù)據(jù)處理能力為10Gbps。綜合上述，haproxy是性能優(yōu)越的負(fù)載均衡、反向代理服務(wù)器。

三大主流軟件負(fù)載均衡器適用業(yè)務(wù)場景：

1、網(wǎng)站建設(shè)初期，可以選用Nigix/HAproxy作為反向代理負(fù)載均衡（或者流量不大都可以不選用負(fù)載均衡），因?yàn)槠渑渲煤唵危阅芤材軡M足一般的業(yè)務(wù)場景。如果考慮到負(fù)載均衡器是有單點(diǎn)問題，可以采用Nginx+Keepalived/HAproxy+Keepalived避免負(fù)載均衡器自身的單點(diǎn)問題。
2、網(wǎng)站并發(fā)達(dá)到一定程度之后，為了提高穩(wěn)定性和轉(zhuǎn)發(fā)效率，可以使用LVS、畢竟LVS比Nginx/HAproxy要更穩(wěn)定，轉(zhuǎn)發(fā)效率也更高。不過維護(hù)LVS對維護(hù)人員的要求也會更高，投入成本也更大。

注：Niginx與Haproxy比較：Niginx支持七層、用戶量最大，穩(wěn)定性比較可靠。Haproxy支持四層和七層，支持更多的負(fù)載均衡算法，支持session保存等。具體選型看使用場景，目前來說Haproxy由于彌補(bǔ)了一些Niginx的缺點(diǎn)用戶量也不斷在提升。

衡量負(fù)載均衡器好壞的幾個重要因素： 
1、會話率 ：單位時間內(nèi)的處理的請求數(shù) 
2、會話并發(fā)能力：并發(fā)處理能力 
3、數(shù)據(jù)率：處理數(shù)據(jù)能力