三大主流負載均衡器LVS、Nginx、HAproxy詳解

 

 

本文連接： https://blog.csdn.net/lilygg/article/details/89538862

1.LVS

簡介：

LVS的是Linux Virtual Server的簡寫，翻譯爲Linux虛擬服務器，即一個虛擬的服務器集羣系統，
是由我國章文嵩博士在1998年5月所研究成立，也是中國國內最先出現的自由軟件項目之一。
LVS由2部分程序組成，包括 ipvs 和 ipvsadm
1. ipvs(ip virtual server)：一段代碼工做在內核空間，叫ipvs，是真正生效實現調度的代碼。
2. ipvsadm：另一段是工做在用戶空間，叫ipvsadm，負責爲ipvs內核框架編寫規則，定義誰是集羣服務，而誰是後端真實的服務器(Real Server)

 

 

LVS相關的幾種IP:

VIP :（virtual IP）   LVS服務器上接收外網數據報文的網卡IP地址
DIP: （director IP）  LVS服務器上發送數據報文到real server的網卡IP地址
RIP :（real server）  真實服務器上的IP，即提供服務的服務器IP(常簡稱爲RS)
CIP :（client IP ）   客戶端的IP

 

工做模式：

LVS經常使用的工做模式有DR模式、TUN模式、以及NAT模式

 

1.DR模式

直接路由: Director Router

(1).工做原理

每一個RS（Real Server）上都有兩個IP：VIP和RIP，可是VIP是隱藏的，即不能提供解析等功能，
只是用來作請求回覆的源IP的，Director（VS）上只須要一個網卡，在該網卡上配置兩個IP：VIP和DIP，
在VS接收到客戶端的請求後，VS根據負載算法選擇一臺RS的網卡mac做爲客戶端請求包中的目標mac，
經過arp轉交給後端RS處理，後端RS再經過本身的路由網關回復給客戶端client。

 

(2).特色

1.各DIP（VS）必須與 RIP（RS） 在同一局域網內(即具備相同的廣播域)，且兩個有相同的目標地址（vip）；
2.RS的RIP可使用私有地址，也可使用公網地址，以方便配置；不支持支持端口映射；
3.RS可使用必須爲uninx操做系統（OS）；且RS須要配置vip但不作響應；
4.Director（VS）僅負責處理入站請求，響應報文由RS( Real server) 直接發往客戶端；
5.Real server（RS）不能將網關指向DIP（DS），而直接使用前端網關響應請求報文；

 

(3).優缺點

優勢：

負載均衡器VS只負責將請求包分發給物理服務器RS，而物理服務器RS將應答包直接發給用戶。因此，負載均衡器VS能處理很巨大的請求量。
這種方式，一臺負載均衡能爲超過100臺的物理服務器服務，負載均衡器再也不是系統的瓶頸。
使用LVS/DR方式，若是你的負載均VS擁有100M的全雙工網卡的話，就能使得整個Virtual Server能達到1G的吞吐量，甚至更高；

 

缺點：

這種方式須要全部的DIR和RIP都在同一廣播域；不支持異地容災。

總結：

LVS/DR是三種模式中性能最高的一種模式，比LVS-NAT模式下負載的RS serve更多，一般在100臺左右，對網絡環境要求更高，也是平常應用的最多的一種工做模式。

 

2.TUN模式

隧道模式: tunnel

 

(1).工做原理

它的鏈接調度和管理與LVS/NAT中的同樣，利用ip隧道技術的原理，即在原有的客戶端請求包頭中再加一層IP Tunnel的包頭ip首部信息，
不改變原來整個請求包信息，只是新增了一層ip首部信息，再利用路由原理將請求發給RS server，不過要求的是全部的server必須支持」IPTunneling」或者」IP Encapsulation」協議。

 

(2).特色

1.RIP、VIP、DIP全是公網地址
2.RS的網關不會也不可能指向DIP
3.全部的請求報文經由Director Server，但響應報文必須不能進過Director Server
4.不支持端口映射,
5.RS的系統必須支持隧道

 

(3).優缺點

優勢：

1.不須要調度應答報文，負載能力強；
2.服務器和調度器能夠不在同一個VLAN中；
3.支持廣域負載均衡；

缺點：

1.全部的服務器必須支持「IP Tunneling」協議，需安裝內核模塊，安裝複雜；
2.創建IP隧道的開銷大；
3.服務器須要聯通外網，風險較大；
4.不支持端口映射；

3.NAT模式

NAT（Network address translation）即網絡地址轉換，做爲一種過渡解決手段，能夠用來減小對全球合法IP地址的需求。
簡單的說，NAT就是在內部專用網絡中使用內部地址，而當內部節點要與外界網絡發生聯繫時，就在邊緣路由器或者防火牆處，
將內部地址轉換成全局地址，從而使得在外部公共網（Internet）上使用一個和數個合法IP地址正常傳輸數據。
其中，這裏的外網和內網是相對來說的，下面假設可以訪問互聯網的網絡爲外網。

 

(1).工做原理

當數據包到達VS時，VS作目標地址轉換（DNAT），將目標IP改成RS的IP。RS接收到數據包之後，彷彿是客戶端直接發給它的同樣。
RS處理完，返回響應時，源IP是RIP，目標IP是客戶端的IP。這時RS的包經過網關（VS）中轉，VS會作源地址轉換（SNAT），
將包的源地址改成VIP，這樣，這個包對客戶端看起來就彷彿是VS直接返回給它的

 

(2). 特色

1.RS應該使用私有地址，RS的網關必須指向DIP
2.DIP和RIP必須在同一個網段內
3.請求和響應報文都須要通過DS，高負載場景中，DS易成爲性能瓶頸
4.支持端口映射
5.RS可使用任意操做系統
6.缺陷：對Director Server壓力會比較大，請求和響應都需通過director server

 

(3).優缺點

優勢：

集羣中的物理服務器可使用任何支持TCP/IP操做系統，物理服務器能夠分配Internet的保留私有地址，只有負載均衡器須要一個合法的IP地址。

缺點：

擴展性有限；當服務器節點（普通PC服務器）數據增加到20個或更多時,負載均衡器將成爲整個系統的瓶頸，由於全部的請求包和應答包都須要通過負載均衡器再生。

總結：

LVS不管NAT及DR模式，均要求VS和RS在同一個網段內，NAT須要把VS看成各個RS的默認網關，
DR模式採用修改mac地址直接從數據鏈路層轉發、要求必須在同一個物理網段內

2.Nginx

1.簡介

Nginx是一款輕量級的Web服務器/反向代理服務器及電子郵件（IMAP/POP3）代理服務器，在BSD-like 協議下發行。其特色是佔有內存少，併發能力強。
國內使用nginx網站用戶有：百度、京東、新浪、網易、騰訊、淘寶等。

2.工做原理

Nginx由內核和模塊組成。Nginx自己作的工做實際不多，當它接到一個HTTP請求時，它僅僅是經過查找配置文件將這次請求映射到一個location block，
而此location中所配置的各個指令則會啓動不一樣的模塊去完成工做，所以模塊能夠看作Nginx真正的勞動工做者。
一般一個location中的指令會涉及一個handler模塊和多個filter模塊（固然，多個location能夠複用同一個模塊）。
handler模塊負責處理請求，完成響應內容的生成，而filter模塊對響應內容進行處理。用戶根據本身的須要開發的模塊都屬於第三方模塊。正是有了這麼多模塊的支撐，Nginx的功能纔會如此強大。

Nginx的模塊從結構上分爲：

核心模塊：HTTP模塊、EVENT模塊和MAIL模塊
基礎模塊：HTTP Access模塊、HTTP FastCGI模塊、HTTP Proxy模塊和HTTP Rewrite模塊，
第三方模塊：HTTP Upstream Request Hash模塊、Notice模塊和HTTP Access Key模塊。

 

Nginx的模塊從功能上分爲：

Core    ： 核心模塊；構建nginx基礎服務、管理其餘模塊。
Handlers： 處理器模塊；此類模塊直接處理請求，並進行輸出內容和修改headers信息等操做。Handlers處理器模塊通常只能有一個。
Filters ： 過濾器模塊；此類模塊主要對其餘處理器模塊輸出的內容進行修改操做，最後由Nginx輸出。
Proxies ： 代理類模塊；此類模塊是Nginx的HTTP Upstream之類的模塊，這些模塊主要與後端一些服務好比FastCGI等進行交互，實現服務代理和負載均衡等功能。

Nginx的核心模塊：主要負責創建nginx服務模型、管理網絡層和應用層協議、以及啓動針對特定應用的一系列候選模塊。
其餘模塊負責分配給web服務器的實際工做：
    (1) 當Nginx發送文件或者轉發請求到其餘服務器，由Handlers(處理模塊)或Proxies（代理類模塊）提供服務；
    (2) 當須要Nginx把輸出壓縮或者在服務端加一些東西，由Filters(過濾模塊)提供服務。

 

Nginx模塊處理流程：

1.客戶端發送HTTP請求
2.Nginx基於配置文件中的位置選擇一個合適的處理模塊
3.負載均衡模塊選擇一臺後端服務器 (若是有)
4.處理模塊進行處理並把輸出緩衝放到第一個過濾模塊上
5.第一個過濾模塊處理後輸出給第二個過濾模塊 
6.而後第二個過濾模塊又到第三個 
7.依此類推，最後把響應發給客戶端。

 

Nginx請求處理流程：

Nginx在啓動時會以daemon形式在後臺運行，採用多進程+異步非阻塞IO事件模型來處理各類鏈接請求。
多進程模型包括一個master進程，多個worker進程，通常worker進程個數是根據服務器CPU核數來決定的。
master進程負責管理Nginx自己和其餘worker進程。

1.操做系統提供的機制（例如 epoll, kqueue 等）產生相關的事件。
2.接收和處理這些事件，如是接收到數據，則產生更高層的 request 對象。
3.處理 request 的 header 和 body。
4.產生響應，併發送回客戶端。
5.完成 request 的處理。
6.從新初始化定時器及其餘事件。

 

Nginx進程模型

Nginx默認採用多進程工做方式，Nginx啓動後，會運行一個master進程和多個worker進程。
master充當整個進程組與用戶的交互接口，同時對進程進行監護，管理worker進程來實現重啓服務、平滑升級、更換日誌文件、配置文件實時生效等功能。
worker用來處理基本的網絡事件，worker之間是平等的，他們共同競爭來處理來自客戶端的請求。

 

3.功能

Nginx能作： 正向代理  反向代理  負載均衡  HTTP服務器(包含動靜分離)

 

(1).正向代理

正向代理（Forward Proxy）：一般都被簡稱爲代理，就是在用戶沒法正常訪問外部資源，
比方說受到GFW的影響沒法訪問twitter的時候，咱們能夠經過代理的方式，讓用戶繞過防火牆，
從而鏈接到目標網絡或者服務。

 

正向代理的工做原理就像一個跳板，好比：我訪問不了google.com，可是我能訪問一個代理服務器A，A能訪問google.com，
因而我先連上代理服務器A，告訴他我須要google.com的內容，A就去取回來，而後返回給我。從網站的角度，
只在代理服務器來取內容的時候有一次記錄，有時候並不知道是用戶的請求，也隱藏了用戶的資料，這取決於代理告不告訴網站。

 

正向代理是一個位於客戶端和原始服務器之間的服務器。爲了從原始服務器取得內容，客戶端向代理髮送一個請求並指定目標(原始服務器)，
而後代理向原始服務器轉交請求並將得到的內容返回給客戶端。

(2).反向代理

反向代理（Reverse Proxy）：是指以代理服務器來接受internet上的鏈接請求，而後將請求轉發給內部網絡上的服務器，
並將從服務器上獲得的結果返回給internet上請求鏈接的客戶端，此時代理服務器對外就表現爲一個服務器。

 

舉個例子，好比我想訪問 http://www.test.com/readme，但www.test.com上並不存在readme頁面，因而他是偷偷從另一臺服務器上取回來，
而後做爲本身的內容返回用戶，但用戶並不知情。這裏所提到的 www.test.com 這個域名對應的服務器就設置了反向代理功能。

 

反向代理服務器對於客戶端而言它就像是原始服務器，而且客戶端不須要進行任何特別的設置。客戶端向反向代理的命名空間中的內容發送普通請求，
接着反向代理服務器將判斷向何處(原始服務器)轉交請求，並將得到的內容返回給客戶端，就像這些內容本來就是它本身的同樣。

總結：

正向代理：針對客戶端而言，代理服務器代理客戶端，轉發請求，並將得到的內容返回給客戶端。
反向代理：針對客戶端而言，代理服務器就像是原始服務器,代理集羣的web節點服務器返回結果。

(3).負載均衡

負載均衡也是Nginx經常使用的一個功能，負載均衡其意思就是分攤到多個操做單元上進行執行，例如Web服務器、FTP服務器、企業關鍵應用服務器和其它關鍵任務服務器等，從而共同完成工做任務。
簡單而言就是當有2臺或以上服務器時，根據規則隨機的將請求分發到指定的服務器上處理，負載均衡配置通常都須要同時配置反向代理，經過反向代理跳轉到負載均衡。
Nginx目前支持自帶3種負載均衡策略，還有2種經常使用的第三方策略。

1.輪詢（rr）

按照輪詢（默認）方式進行負載，每一個請求按時間順序逐一分配到不一樣的後端服務器，若是後端服務器down掉，能自動剔除。
雖然這種方式簡便、成本低廉。但缺點是：可靠性低和負載分配不均衡。

2.權重(weight)

指定輪詢概率，weight和訪問比率成正比，用於後端服務器性能不均的狀況。

upstream westos{
     server 172.25.66.2:80  weight=9;
     server 172.25.66.3:80  weight=1;
}

 

3.ip哈希（ip_hash）

上面的2種方式都有一個問題，那就是下一個請求來的時候請求可能分發到另一個服務器，當咱們的程序不是無狀態的時候（採用了session保存數據），
這時候就有一個很大的很問題了，好比把登陸信息保存到了session中，那麼跳轉到另一臺服務器的時候就須要從新登陸了，
因此不少時候咱們須要一個客戶只訪問一個服務器，那麼就須要用ip_hash了，ip_hash的每一個請求按訪問ip的hash結果分配，
這樣每一個訪客固定訪問一個後端服務器，能夠解決session的問題。

ip_hash： 來自同一個IP的請求會分發到相同的後端服務器

 

upstream westos{
	 ip_hash;
     server 172.25.66.2:80;
     server 172.25.66.3:80;
}

 

第三方策略：

1.fair

按後端服務器的響應時間來分配請求，響應時間短的優先分配。

 

upstream backend{
	 fair;
     server 172.25.66.2:80;
     server 172.25.66.3:80;
}

 

2.url_hash

按訪問url的hash結果來分配請求，使每一個url定向到同一個後端服務器，後端服務器爲緩存時比較有效。 
在upstream中加入hash語句，server語句中不能寫入weight等其餘的參數，hash_method是使用的hash算法。

upstream backend{
	 hash $request_uri; 
     hash_method crc32; 
     server 172.25.66.2:80;
     server 172.25.66.3:80;
}

 

(4).HTTP服務器

Nginx自己也是一個靜態資源的服務器，當只有靜態資源的時候，就可使用Nginx來作服務器，同時如今也很流行動靜分離，
就能夠經過Nginx來實現，動靜分離是讓動態網站裏的動態網頁根據必定規則把不變的資源和常常變的資源區分開來，動靜資源作好了拆分之後，
咱們就能夠根據靜態資源的特色將其作緩存操做，這就是網站靜態化處理的核心思路。

 

4.優勢

(1).支持高併發

官方測試Nginx可以支撐5萬併發鏈接，實際生產環境中能夠支撐2~4萬併發鏈接數。
緣由主要是Nginx使用了最新的epoll（Linux2.6內核）和kqueue（freeBSD）網路I/O模型，
而Apache使用的是傳統的Select模型，其比較穩定的Prefork模式爲多進程模式，須要常常派生子進程，因此消耗的CPU等服務器資源，要比Nginx高不少。

 

(2).內存消耗少

Nginx+PHP（FastCGI）服務器，在3萬併發鏈接下，開啓10個Nginx進程消耗150MB內存，15MB*10=150MB，開啓的64個PHP-CGI進程消耗1280內存，20MB*64=1280MB，加上系統自身消耗的內存，總共消耗不到2GB的內存。
若是服務器的內存比較小，徹底能夠只開啓25個PHP-CGI進程，這樣PHP-CGI消耗的總內存數才500MB。

 

(3).成本低廉

購買F5BIG-IP、NetScaler等硬件負載均衡交換機，須要十多萬到幾十萬人民幣，而Nginx爲開源軟件，採用的是2-clause BSD-like協議，能夠免費試用，而且可用於商業用途。
BSD開源協議是一個給使用者很大自由的協議，協議指出能夠自由使用、修改源代碼、也能夠將修改後的代碼做爲開源或專用軟件再發布。

(4).配置簡單

網絡和程序同樣通俗易懂，即便，非專用系統管理員也能看懂。

 

(5).支持Rewrite重寫

Rewrite:重定向；可以根據域名、URL的不一樣，將http請求分到不一樣的後端服務器羣組。

 

(6).內置健康檢查

若是NginxProxy後端的某臺Web服務器宕機了，不會影響前端的訪問。

 

(7).節省帶寬

支持GZIP壓縮，能夠添加瀏覽器本地緩存的Header頭。

 

(8).支持熱部署

Nginx支持熱部署，它的自動特別容易，而且，幾乎能夠7天*24小時不間斷的運行，
即便運行數個月也不須要從新啓動，還可以在不間斷服務的狀況下，對軟件版本進行升級。

3.HAproxy

1.簡介

HAProxy是一個使用C語言編寫的自由及開放源代碼軟件，它提供高可用性、負載均衡，以及基於TCP(第四層)和HTTP（第七層）的應用程序代理。
HAProxy特別適用於那些負載特大的web站點，這些站點一般又須要會話保持或七層處理。HAProxy運行在當前的硬件上，
徹底能夠支持數以萬計的併發鏈接。而且它的運行模式使得它能夠很簡單安全的整合進您當前的架構中， 同時能夠保護你的web服務器不被暴露到網絡上。

 

2.原理

HAProxy實現了一種事件驅動, 單一進程模型，此模型支持很是大的併發鏈接數。多進程或多線程模型受內存限制 、系統調度器限制以及無處不在的鎖限制，不多能處理數千併發鏈接。
事件驅動模型由於在有更好的資源和時間管理的用戶空間(User-Space) 實現全部這些任務，因此沒有這些問題。
此模型的弊端是，在多核系統上，這些程序一般擴展性較差。這就是爲何他們必須進行優化以使每一個CPU時間片(Cycle)作更多的工做

 

HAProxy的負載均衡算法：

1. roundrobin：簡單的輪詢
2. static-rr：權重輪詢
3. leastconn：最少鏈接者優先
4. source：根據請求源IP,這個跟Nginx的ip_hash機制相似
5. ri：根據請求的URI
6. rl_param：表示根據請求的URI參數‘balance url_param’requires an URL parameter name;
7. hdr(name)：根據HTTP請求頭來鎖定每一次HTTP請求
8. rdp-cookie(name)：根據cookie來鎖定並哈希每一次TCP請求

 

3.優勢

1.免費開源，穩定性也是很是好。單HAproxy也跑得不錯，穩定性能夠與硬件級的F5相媲美。
2.根據官方文檔，HAproxy能夠跑滿10Gbps，這個數值做爲軟件級負載均衡器是至關驚人的。
3.HAproxy支持鏈接拒絕:由於維護一個鏈接的打開的開銷是很低的，有時咱們很須要限制攻擊蠕蟲（attack bots），也就是說限制它們的鏈接打開從而限制它們的危害。這個已經爲一個陷於小型DDoS攻擊的網站開發了並且已經拯救了不少站點，這個優勢也是其它負載均衡器沒有的。
4.HAproxy支持全透明代理（已具有硬件防火牆的典型特色）:能夠用客戶端IP地址或者任何其餘地址來鏈接後端服務器。這個特性僅在Linux 2.4/2.6內核打了tcp proxy補丁後纔可使用。這個特性也使得爲某特殊服務器處理部分流量同時又不修改服務器的地址成爲可能。
5.HAproxy現多於線上的Mysql集羣環境，咱們經常使用於它做爲MySQL（讀）負載均衡。
6.自帶強大的監控服務器狀態的頁面，實際環境中咱們結合Nagios進行郵件或短信報警。
7.HAproxy支持虛擬主機，許多朋友說它不支持虛擬主機是錯誤的，經過測試咱們知道，HAProxy是支持虛擬主機的。

 

 

4.比較LVS、Nginx、HAproxy優缺點

三大主流負載均衡器： LVS  Nginx  HAproxy

(1).LVS

優勢：

1.抗負載能力強,工做在網絡4層之上,僅做分發之用，沒有流量的產生，這個特色也決定了它在負載均衡軟件裏的性能最強的，對內存和cpu資源消耗比較低。
2.配置性比較低，這是一個缺點也是一個優勢，由於沒有可太多配置的東西，因此並不須要太多接觸，大大減小了人爲出錯的概率。
3.工做穩定，由於其自己抗負載能力很強，自身有完整的雙機熱備方案，如LVS+Keepalived，不過咱們在項目實施中用得最多的仍是LVS/DR+Keepalived。
4.無流量，LVS只分發請求，而流量並不從它自己出去，這點保證了均衡器IO的性能不會收到大流量的影響。
5.應用範圍比較廣，由於LVS工做在4層，因此它幾乎能夠對全部應用作負載均衡，包括http、數據庫、在線聊天室等等。

 

缺點：

1.軟件自己不支持正則表達式處理，不能作動靜分離；而如今許多網站在這方面都有較強的需求，這個是Nginx/HAProxy+Keepalived的優點所在。
2.若是是網站應用比較龐大的話，LVS/DR+Keepalived實施起來就比較複雜了，特別後面有Windows Server的機器的話，若是實施及配置還有維護過程就比較複雜了，相對而言，Nginx/HAProxy+Keepalived就簡單多了。

 

(2).Nginx

優勢：

1.工做在網絡的7層之上，能夠針對http應用作一些分流的策略，好比針對域名、目錄結構。它的正則規則比HAProxy更爲強大和靈活，這也是它目前普遍流行的主要緣由之一，Nginx單憑這點可利用的場合就遠多於LVS了。
2.對網絡穩定性的依賴很是小，理論上能ping通就就能進行負載功能。
3.安裝和配置比較簡單，測試起來比較方便，它基本能把錯誤用日誌打印出來。LVS的配置、測試就要花比較長的時間了，LVS對網絡依賴比較大。
3.抗高併發且穩定，在硬件不差的狀況下通常能支撐幾萬次的併發量，負載度比LVS相對小些。
4.能夠經過端口檢測到服務器內部的故障，好比根據服務器處理網頁返回的狀態碼、超時等等，而且會把返回錯誤的請求從新提交到另外一個節點。
5.不只僅是一款優秀的負載均衡器/反向代理軟件，它同時也是功能強大的Web應用服務器。LNMP也是近幾年很是流行的web架構，在高流量的環境中穩定性也很好。
6.做爲Web反向加速緩存愈來愈成熟了，速度比傳統的Squid服務器更快，能夠考慮用其做爲反向代理加速器。
7.可做爲中層反向代理使用，這一層面Nginx基本上無對手，惟一能夠對比Nginx的就只有lighttpd了，不過lighttpd目前尚未作到Nginx徹底的功能，配置也不那麼清晰易讀，社區資料也遠遠沒Nginx活躍。
8.可做爲靜態網頁和圖片服務器，這方面的性能也無對手。
9.Nginx社區很是活躍，第三方模塊也不少。

 

缺點：

1.Nginx僅能支持http、https和Email協議，適用範圍小。
2.對後端服務器的健康檢查，只支持經過端口來檢測，不支持經過url來檢測。不支持Session的直接保持，但能經過ip_hash來解決。

(3).HAproxy

優勢：

1.支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機；
2.支持Session的保持，Cookie的引導；同時支持經過獲取指定的url來檢測後端服務器的狀態。可以補充Nginx的一些缺點。
3.HAProxy跟LVS相似，自己就只是一款負載均衡軟件；單純從效率上來說HAProxy會比Nginx有更出色的負載均衡速度，在併發處理上也是優於Nginx的,低於Lvs。
4.HAProxy能夠對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。
5.HAProxy負載均衡策略很是多，好比：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)
6.免費開源，穩定性也是很是好，能夠與LVS相媲美；
7.自帶強大的監控服務器狀態的頁面，實際環境中咱們結合Nagios進行郵件或短信報警；

缺點：

1. 不支持POP/SMTP協議 SPDY協議；
2. 不能作Web服務器，即不支持HTTP cache功能；
3. 重載配置的功能須要重啓進程，雖然也是soft restart，但沒有Nginx的reaload更爲平滑和友好；
4. 多進程模式支持不夠好；
5. 正則弱於Nginx；
6. 日誌依賴於syslogd,不支持Apache日誌

適用場景：

1.網站建設初期，能夠選用Nigix/HAproxy做爲反向代理負載均衡（或者流量不大均可以不選用負載均衡），由於其配置簡單，性能也能知足通常的業務場景。
  若是考慮到負載均衡器是有單點問題，能夠採用Nginx/HAproxy+Keepalived來避免。
2.網站併發達到必定程度以後，爲了提升穩定性和轉發效率，可使用LVS、畢竟LVS比Nginx/HAproxy要更穩定，轉發效率也更高。不過維護LVS對維護人員的要求也會更高，投入成本也更大。

參考博客： https://blog.csdn.net/wy757510722/article/details/75267431
參考簡書： https://www.jianshu.com/p/6215e5d24553