一、Nginx優點：

1、工作在網路7層之上，可針對http應用做一些分流的策略，如針對域名、目錄結構，它的正規規則比HAProxy更為強大和靈活，所以，目前為止廣泛流行。

2、Nginx對網路穩定性的依賴非常小，理論上能ping通就能進行負載功能。

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

4、可以承擔高負載壓力且穩定，硬體不差的情況下一般能支撐幾萬次的併發量，負載度比LVS小。

5、Nginx可以通過埠檢測到伺服器內部的故障，如根據伺服器處理網頁返回的狀態碼、超時等，並會把返回錯誤的請求重新提交到另一個節點。

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

7、可作為中層反向代理使用。

8、可作為靜態網頁和圖片伺服器。

9、Nginx社群活躍，第三方模組非常多，相關的資料在網上比比皆是。

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

Nginx缺點：

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

2、對後端伺服器的健康檢查，只支援通過埠檢測，不支援url來檢測。比如使用者正在上傳一個檔案，而處理該上傳的節點剛好在上傳過程中出現故障，Nginx會把上傳切到另一臺伺服器重新處理，而LVS就直接斷掉了，如果是上傳一個很大的檔案或者很重要的檔案的話，使用者可能會因此而不滿。

二、LVS優點：

1、抗負載能力強、是工作在網路4層之上僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟體裡的效能最強的，對記憶體和cpu資源消耗比較低。

2、配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的機率。

3、工作穩定，因為其本身抗負載能力很強，自身有完整的雙機熱備方案，如LVS+Keepalived，不過我們在專案實施中用得最多的還是LVS/DR+Keepalived。

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

5、應用範圍比較廣，因為LVS工作在4層，所以它幾乎可以對所有應用做負載均衡，包括http、資料庫、線上聊天室等等。

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

LVS的缺點：

1、軟體本身不支援正則表示式處理，不能做動靜分離；而現在許多網站在這方面都有較強的需求，這個是Nginx/HAProxy+Keepalived的優勢所在。

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

三、HAProxy優點：

1、HAProxy是支援虛擬主機的，可以工作在4、7層(支援多網段)

2、HAProxy的優點能夠補充Nginx的一些缺點，比如支援Session的保持，Cookie的引導；同時支援通過獲取指定的url來檢測後端伺服器的狀態。

3、HAProxy跟LVS類似，本身就只是一款負載均衡軟體；單純從效率上來講HAProxy會比Nginx有更出色的負載均衡速度，在併發處理上也是優於Nginx的。

4、HAProxy支援TCP協議的負載均衡轉發，可以對MySQL讀進行負載均衡，對後端的MySQL節點進行檢測和負載均衡，大家可以用LVS+Keepalived對MySQL主從做負載均衡。

5、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. 多程序模式支援不夠好