三大主流負載均衡器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 Route

(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的。
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. 多進程模式支持不夠好；

適用場景：

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

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

1.LVS

2.Nginx

3.HAproxy

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

HTML頁面關於高分屏的設置

北歐瑞典挪威芬蘭瑞士TikTok海外網紅與YouTube博主的合作模式

歐洲英國德國法國TikTok與YouTube海外網紅達人的完美合作策略

druid數據源 xml配置

ActiveMQ集羣方案（上）

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

redis-bgrewriteaof問題--持久化恢復問題

有關linux下redis overcommit_memory的問題

頂級技術網站博客彙總

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結