LVS、Nginx及HAProxy的工作原理和優(yōu)缺點

這篇文章主要介紹“LVS、Nginx及HAProxy的工作原理和優(yōu)缺點”，在日常操作中，相信很多人在LVS、Nginx及HAProxy的工作原理和優(yōu)缺點問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”LVS、Nginx及HAProxy的工作原理和優(yōu)缺點”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

LVS

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

LVS 自從1998年開始，發(fā)展到現(xiàn)在已經(jīng)是一個比較成熟的技術項目了。

LVS 的體系結構

LVS 架設的服務器集群系統(tǒng)有三個部分組成：

(1) 最前端的負載均衡層，用 Load Balancer 表示

(2) 中間的服務器集群層，用 Server Array 表示

(3) ***端的數(shù)據(jù)共享存儲層，用 Shared Storage 表示

LVS 負載均衡機制

LVS 不像 HAProxy 等七層軟負載面向的是 HTTP 包，所以七層負載可以做的 URL 解析等工作，LVS 無法完成。

LVS 是四層負載均衡，也就是說建立在 OSI 模型的第四層——傳輸層之上，傳輸層上有我們熟悉的 TCP/UDP，LVS 支持 TCP/UDP  的負載均衡。因為 LVS 是四層負載均衡，因此它相對于其它高層負載均衡的解決辦法，比如 DNS  域名輪流解析、應用層負載的調度、客戶端的調度等，它的效率是非常高的。

所謂四層負載均衡 ，也就是主要通過報文中的目標地址和端口。七層負載均衡 ，也稱為“內容交換”，也就是主要通過報文中的真正有意義的應用層內容。

LVS 的轉發(fā)主要通過修改 IP 地址(NAT 模式，分為源地址修改 SNAT 和目標地址修改 DNAT)、修改目標 MAC(DR 模式)來實現(xiàn)。

NAT 模式：網(wǎng)絡地址轉換

NAT(Network Address Translation)是一種外網(wǎng)和內網(wǎng)地址映射的技術。

NAT 模式下，網(wǎng)絡數(shù)據(jù)報的進出都要經(jīng)過 LVS 的處理。LVS 需要作為 RS(真實服務器)的網(wǎng)關。

當包到達 LVS 時，LVS 做目標地址轉換(DNAT)，將目標 IP 改為 RS 的 IP。RS 接收到包以后，仿佛是客戶端直接發(fā)給它的一樣。RS  處理完，返回響應時，源 IP 是 RS IP，目標 IP 是客戶端的 IP。這時 RS 的包通過網(wǎng)關(LVS)中轉，LVS  會做源地址轉換(SNAT)，將包的源地址改為 VIP，這樣，這個包對客戶端看起來就仿佛是 LVS 直接返回給它的。

DR 模式：直接路由

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

詳細來看，一個請求過來時，LVS 只需要將網(wǎng)絡幀的 MAC 地址修改為某一臺 RS 的 MAC，該包就會被轉發(fā)到相應的 RS 處理，注意此時的源 IP  和目標 IP 都沒變，LVS 只是做了一下移花接木。RS 收到 LVS 轉發(fā)來的包時，鏈路層發(fā)現(xiàn) MAC 是自己的，到上面的網(wǎng)絡層，發(fā)現(xiàn) IP  也是自己的，于是這個包被合法地接受，RS 感知不到前面有 LVS 的存在。而當 RS 返回響應時，只要直接向源 IP(即用戶的 IP)返回即可，不再經(jīng)過  LVS。

DR 負載均衡模式數(shù)據(jù)分發(fā)過程中不修改 IP 地址，只修改 mac 地址，由于實際處理請求的真實物理 IP 地址和數(shù)據(jù)請求目的 IP  地址一致，所以不需要通過負載均衡服務器進行地址轉換，可將響應數(shù)據(jù)包直接返回給用戶瀏覽器，避免負載均衡服務器網(wǎng)卡帶寬成為瓶頸。因此，DR  模式具有較好的性能，也是目前大型網(wǎng)站使用最廣泛的一種負載均衡手段。

LVS 的優(yōu)點

• 抗負載能力強、是工作在傳輸層上僅作分發(fā)之用，沒有流量的產(chǎn)生，這個特點也決定了它在負載均衡軟件里的性能***的，對內存和 cpu 資源消耗比較低。

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

• 工作穩(wěn)定，因為其本身抗負載能力很強，自身有完整的雙機熱備方案，如 LVS+Keepalived。

• 無流量，LVS 只分發(fā)請求，而流量并不從它本身出去，這點保證了均衡器 IO 的性能不會受到大流量的影響。

• 應用范圍比較廣，因為 LVS 工作在傳輸層，所以它幾乎可以對所有應用做負載均衡，包括 http、數(shù)據(jù)庫、在線聊天室等等。

LVS 的缺點

• 軟件本身不支持正則表達式處理，不能做動靜分離;而現(xiàn)在許多網(wǎng)站在這方面都有較強的需求，這個是 Nginx、HAProxy+Keepalived  的優(yōu)勢所在。

• 如果是網(wǎng)站應用比較龐大的話，LVS/DR+Keepalived  實施起來就比較復雜了，相對而言，Nginx/HAProxy+Keepalived就簡單多了。

Nginx

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

Nignx 的架構設計

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

反過來，Nginx 的架構設計是采用模塊化的、基于事件驅動、異步、單線程且非阻塞。

Nginx 大量使用多路復用和事件通知，Nginx 啟動以后，會在系統(tǒng)中以 daemon 的方式在后臺運行，其中包括一個 master  進程，n(n>=1) 個 worker 進程。所有的進程都是單線程(即只有一個主線程)的，且進程間通信主要使用共享內存的方式。

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

Nginx 負載均衡

Nginx 負載均衡主要是對七層網(wǎng)絡通信模型中的第七層應用層上的 http、https 進行支持。

Nginx 是以反向代理的方式進行負載均衡的。反向代理(Reverse Proxy)方式是指以代理服務器來接受 Internet  上的連接請求，然后將請求轉發(fā)給內部網(wǎng)絡上的服務器，并將從服務器上得到的結果返回給 Internet  上請求連接的客戶端，此時代理服務器對外就表現(xiàn)為一個服務器。

Nginx 實現(xiàn)負載均衡的分配策略有很多，Nginx 的 upstream 目前支持以下幾種方式：

• 輪詢(默認)：每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器 down 掉，能自動剔除。

• weight：指定輪詢幾率，weight 和訪問比率成正比，用于后端服務器性能不均的情況。

• ip_hash：每個請求按訪問 ip 的 hash 結果分配，這樣每個訪客固定訪問一個后端服務器，可以解決 session 的問題。

• fair(第三方)：按后端服務器的響應時間來分配請求，響應時間短的優(yōu)先分配。

• url_hash(第三方)：按訪問 url 的 hash 結果來分配請求，使每個 url 定向到同一個后端服務器，后端服務器為緩存時比較有效。

Nginx 的優(yōu)點

• 跨平臺：Nginx 可以在大多數(shù) Unix like OS編譯運行，而且也有 Windows 的移植版本

• 配置異常簡單：非常容易上手。配置風格跟程序開發(fā)一樣，神一般的配置

• 非阻塞、高并發(fā)連接：官方測試能夠支撐5萬并發(fā)連接，在實際生產(chǎn)環(huán)境中跑到2～3萬并發(fā)連接數(shù)

• 事件驅動：通信機制采用 epoll 模型，支持更大的并發(fā)連接

• Master/Worker 結構：一個 master 進程，生成一個或多個 worker 進程

• 內存消耗小：處理大并發(fā)的請求內存消耗非常小。在3萬并發(fā)連接下，開啟的10個 Nginx 進程才消耗150M 內存(15M*10=150M)

• 內置的健康檢查功能：如果 Nginx 代理的后端的某臺 Web 服務器宕機了，不會影響前端訪問

• 節(jié)省帶寬：支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭

• 穩(wěn)定性高：用于反向代理，宕機的概率微乎其微

Nginx 的缺點

• Nginx 僅能支 持http、https 和 Email 協(xié)議，這樣就在適用范圍上面小些，這個是它的缺點

• 對后端服務器的健康檢查，只支持通過端口來檢測，不支持通過 ur l來檢測。不支持 Session 的直接保持，但能通過 ip_hash 來解決

HAProxy

HAProxy 支持兩種代理模式 TCP(四層)和HTTP(七層)，也是支持虛擬主機的。

HAProxy 的優(yōu)點能夠補充 Nginx 的一些缺點，比如支持 Session 的保持，Cookie 的引導;同時支持通過獲取指定的 url  來檢測后端服務器的狀態(tài)。

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

HAProxy 支持 TCP 協(xié)議的負載均衡轉發(fā)，可以對 MySQL 讀進行負載均衡，對后端的 MySQL 節(jié)點進行檢測和負載均衡，大家可以用  LVS+Keepalived 對 MySQL 主從做負載均衡。

HAProxy  負載均衡策略非常多：Round-robin(輪循)、Weight-round-robin(帶權輪循)、source(原地址保持)、RI(請求URL)、rdp-cookie(根據(jù)cookie)。

到此，關于“LVS、Nginx及HAProxy的工作原理和優(yōu)缺點”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>