常見負載均衡的優勢和缺點對比（Nginx、HAProxy、LVS）

1、Nginx優勢：

一、工做在網絡7層之上，可針對http應用作一些分流的策略，如針對域名、目錄結構，它的正規規則比HAProxy更爲強大和靈活，因此，目前爲止普遍流行。

二、Nginx對網絡穩定性的依賴很是小，理論上能ping通就能進行負載功能。

三、Nginx安裝與配置比較簡單，測試也比較方便，基本能把錯誤日誌打印出來。

四、能夠承擔高負載壓力且穩定，硬件不差的狀況下通常能支撐幾萬次的併發量，負載度比LVS小。

五、Nginx能夠經過端口檢測到服務器內部的故障，如根據服務器處理網頁返回的狀態碼、超時等，並會把返回錯誤的請求從新提交到另外一個節點。

六、不只僅是優秀的負載均衡器/反向代理軟件，同時也是強大的Web應用服務器。LNMP也是近些年很是流行的Web架構，在高流量環境中穩定性也很好。

七、可做爲中層反向代理使用。

八、可做爲靜態網頁和圖片服務器。

九、Nginx社區活躍，第三方模塊很是多。

Nginx常規的和HTTP請求和相應流程圖：

 

 

Nginx缺點：

一、適應範圍較小，僅能支持http、https、Email協議。

二、對後端服務器的健康檢查，只支持經過端口檢測，不支持url來檢測。好比用戶正在上傳一個文件，而處理該上傳的節點恰好在上傳過程當中出現故障，Nginx會把上傳切到另外一臺服務器從新處理，而LVS就直接斷掉了，若是是上傳一個很大的文件或者很重要的文件的話，用戶可能會所以而不滿。

三、 不支持Session的直接保持，但能經過ip_hash來解決，對Big request header的支持不是很好

 

2、LVS優勢：

一、抗負載能力強、是工做在網絡4層之上僅做分發之用，沒有流量的產生，這個特色也決定了它在負載均衡軟件裏的性能最強的，對內存和cpu資源消耗比較低。

二、配置性比較低，這是一個缺點也是一個優勢，由於沒有可太多配置的東西，因此並不須要太多接觸，大大減小了人爲出錯的概率。

三、工做穩定，由於其自己抗負載能力很強，自身有完整的雙機熱備方案，如LVS+Keepalived，不過咱們在項目實施中用得最多的仍是LVS/DR+Keepalived。

四、無流量，LVS只分發請求，而流量並不從它自己出去，這點保證了均衡器IO的性能不會收到大流量的影響。

五、應用範圍比較廣，由於LVS工做在4層，因此它幾乎能夠對全部應用作負載均衡，包括http、數據庫、在線聊天室等等。

六、支持多種負載均衡算法：rr（輪詢），wrr（帶權輪詢）、lc（最小鏈接）、wlc（帶權最小鏈接）

七、LVS工做模式有4種：

     （1）nat地址轉換

     （2）dr直接路由

     （3）tun隧道

     （4）full-nat

LVS DR(Direct Routing)模式的網絡流程圖：

 

LVS的缺點：

一、軟件自己不支持正則表達式處理，不能作動靜分離；而如今許多網站在這方面都有較強的需求，這個是Nginx/HAProxy+Keepalived的優點所在。

二、若是是網站應用比較龐大的話，LVS/DR+Keepalived實施起來就比較複雜了，特別後面有Windows Server的機器的話，若是實施及配置還有維護過程就比較複雜了，相對而言，Nginx/HAProxy+Keepalived就簡單多了。

 

3、HAProxy優勢：

一、HAProxy是支持虛擬主機的，能夠工做在四、7層(支持多網段)

二、HAProxy的優勢可以補充Nginx的一些缺點，好比支持Session的保持，Cookie的引導；同時支持經過獲取指定的url來檢測後端服務器的狀態。

三、HAProxy跟LVS相似，自己就只是一款負載均衡軟件；單純從效率上來說HAProxy會比Nginx有更出色的負載均衡速度，在併發處理上也是優於Nginx的。

四、HAProxy支持TCP協議的負載均衡轉發，能夠對MySQL讀進行負載均衡，對後端的MySQL節點進行檢測和負載均衡，你們能夠用LVS+Keepalived對MySQL主從作負載均衡。

五、HAProxy負載均衡策略很是多，HAProxy的負載均衡算法如今具體有以下8種

①　roundrobin

表示簡單的輪詢，每一個服務器根據權重輪流使用，在服務器的處理時間平均分配的狀況下這是最流暢和公平的算法。該算法是動態的，對於實例啓動慢的服務器權重會在運行中調整。最大支持4095個後端主機；

②　leastconn

鏈接數最少的服務器優先接收鏈接。leastconn建議用於長會話服務，例如LDAP、SQL、TSE等，而不適合短會話協議。如HTTP.該算法是動態的，對於實例啓動慢的服務器權重會在運行中調整。

③　static-rr

每一個服務器根據權重輪流使用，相似roundrobin，但它是靜態的，意味着運行時修改權限是無效的。另外，它對服務器的數量沒有限制。該算法通常不用；

④　source

對請求源IP地址進行哈希，用可用服務器的權重總數除以哈希值，根據結果進行分配。只要服務器正常，同一個客戶端IP地址老是訪問同一個服務器。若是哈希的結果隨可用服務器數量而變化，那麼客戶端會定向到不一樣的服務器；該算法通常用於不能插入cookie的Tcp模式。它還能夠用於廣域網上爲拒絕使用會話cookie的客戶端提供最有效的粘連；該算法默認是靜態的，因此運行時修改服務器的權重是無效的，可是算法會根據「hash-type」的變化作調整。

⑤　uri

表示根據請求的URI左端（問號以前）進行哈希，用可用服務器的權重總數除以哈希值，根據結果進行分配。只要服務器正常，同一個URI地址老是訪問同一個服務器。通常用於代理緩存和反病毒代理，以最大限度的提升緩存的命中率。該算法只能用於HTTP後端；該算法通常用於後端是緩存服務器；該算法默認是靜態的，因此運行時修改服務器的權重是無效的，可是算法會根據「hash-type」的變化作調整。

⑥　url_param

在HTTP GET請求的查詢串中查找<param>中指定的URL參數，基本上能夠鎖定使用特製的URL到特定的負載均衡器節點的要求；該算法通常用於將同一個用戶的信息發送到同一個後端服務器；該算法默認是靜態的，因此運行時修改服務器的權重是無效的，可是算法會根據「hash-type」的變化作調整。

⑦　hdr(name)

在每一個HTTP請求中查找HTTP頭<name>，HTTP頭<name>將被看做在每一個HTTP請求，並針對特定的節點；若是缺乏頭或者頭沒有任何值，則用roundrobin代替；該算法默認是靜態的，因此運行時修改服務器的權重是無效的，可是算法會根據「hash-type」的變化作調整。

⑧　rdp-cookie（name）

爲每一個進來的TCP請求查詢並哈希RDP cookie<name>；該機制用於退化的持久模式，可使同一個用戶或者同一個會話ID老是發送給同一臺服務器。若是沒有cookie，則使用roundrobin算法代替；該算法默認是靜態的，因此運行時修改服務器的權重是無效的，可是算法會根據「hash-type」的變化作調整。

haproxy的工做模型圖：

 

HAPorxy缺點：

1. 不支持POP/SMTP協議

2. 不支持SPDY協議

3. 不支持HTTP cache功能。如今很多開源的lb項目，都或多或少具有HTTP cache功能。

4. 重載配置的功能須要重啓進程，雖然也是soft restart，但沒有Nginx的reaload更爲平滑和友好。

5. 多進程模式支持不夠好

6. 不能作Web服務器即Cache

 

4、三大主流軟件負載均衡器適用的生產場景：

1.網站建設初期，能夠選用Nginx、HAproxy做爲反向代理負載均衡（流量不大時能夠選擇不用負載均衡）由於其配置簡單，性能也能知足通常業務場景。若是考慮到負載均衡器是有單點失敗問題，能夠採用Nginx+Keepalived避免負載均衡器自身單點問題。

2.網站併發達到必定程度後，爲了提升穩定性和轉發效率，可使用LVS，畢竟LVS比Nginx/HAproxy要更穩定，轉發效率也高。