一、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. 多進程模式支持不夠好
本文轉載至：https://blog.csdn.net/qlj324513/article/details/81541282