三大主流軟件負載均衡器對比(LVS、Nginx、HAproxy)
阿新 • • 發佈：2018-03-14
LVS、Nginx HAproxy
(4) full-nat
Nginx:
1. 工作在網絡7層，可以針對http應用做一些分流的策略，比如針對域名，目錄結構
2. Nginx對網絡的依賴較小，理論上能ping通就能進行負載功能
3. Nginx安裝配置比較簡單，測試起來很方便
4. 也可以承擔較高的負載壓力且穩定，nginx是為解決c10k問題而誕生的
5. 對後端服務器的健康檢查，只支持通過端口來檢測，不支持通過url來檢測
6. Nginx對請求的異步處理可以幫助節點服務器減輕負載壓力
7. Nginx僅能支持http、https和Email協議，這樣就在適用範圍較小。
9. Nginx還能做Web服務器即Cache功能。
第6點補充：
什麽是nginx的異步處理：
squid同步處理：瀏覽器發起請求，而後請求會立刻被轉到後端，於是在瀏覽器和後臺之間就建立了一個通道。從請求發起直到請求完成，這條通道都是一直存在的。
nginx異步處理：瀏覽器發起請求，請求不會立刻轉到後端，而是請求數據(header)先收到nignx上，然後nginx再把這個請求發到後端，後端處理完成後把數據返回到nginx上，nginx將數據流發到瀏覽器。
使用異步處理的好處：
1. 假設用戶執行一個上傳文件操作，因為用戶網速又比較慢，因此需要花半個小時才能把文件傳到服務器。squid的同步代理在用戶開始上傳後就和後臺建立了連接，半小時後文件上傳結束，由此可見，後臺服務器連接保持了半個小時；而nginx異步代理就是先將此文件收到nginx上，因此僅僅是nginx和用戶保持了半小時連接，後臺服務器在這半小時內沒有為這個請求開啟連接，半小時後用戶上傳結束，nginx才將上傳內容發到後臺，nginx和後臺之間的帶寬是很充裕的，所以只花了一秒鐘就將請求發送到了後臺，由此可見，後臺服務器連接保持了一秒。同步傳輸花了後臺服務器半個小時，異步傳輸只花一秒，可見優化 程度很大。
2. 在上面這個例子中，假如後臺服務器因為種種原因重啟了，上傳文件就自然中斷了，這對用戶來說是非常惱火的一件事情，想必各位也有上傳文件傳到一半被中斷的 經歷。用nginx代理之後，後臺服務器的重啟對用戶上傳的影響減少到了極點，而nginx是非常穩定的並不需要常去重啟它，即使需要重啟，利用kill -HUP就可以做到不間斷重啟nginx。
3. 異步傳輸可以令負載均衡器更有保障，為什麽這麽說呢？在其它的均衡器（lvs/haproxy/apache等）裏，每個請求都是只有一次機會的，假如用 戶發起一個請求，結果該請求分到的後臺服務器剛好掛掉了，那麽這個請求就失敗了；而nginx因為是異步的，所以這個請求可以重新發往下一個後臺，下一個 後臺返回了正常的數據，於是這個請求就能成功了。還是用用戶上傳文件這個例子，假如不但用了nginx代理，而且用了負載均衡，nginx把上傳文件發往 其中一臺後臺，但這臺服務器突然重啟了，nginx收到錯誤後，會將這個上傳文件發到另一臺後臺，於是用戶就不用再花半小時上傳一遍。
4. 假如用戶上傳一個10GB大小的文件，而後臺服務器沒有考慮到這個情況，那麽後臺服務器豈不要崩潰了。用nginx就可以把這些東西都攔在nginx上，通過nginx的上傳文件大小限制功能來限制，另外nginx性能非常有保障，就放心的讓互聯網上那些另類的用戶和nginx對抗去吧。
用異步傳輸會造成問題：
後臺服務器有提供上傳進度的功能的話，用了nginx代理就無法取得進度，這個需要使用nginx的一個第三方模塊來實現。
第8點補充：
Nginx upstream支持的分配策略及原理：
1. 輪詢(默認)：每個請求按照順序逐一分配到不同的後端服務器。如後端服務器down掉，就切換到另一臺並剔除down的後端主機
2. weight：指定輪詢幾率，weight和訪問比率成正比，用於後端服務器性能不均的情況。
3. ip_hash：每個請求按照訪問ip的hash結果分配，不同ip的請求被分配到後端不同的服務器上，可以解決session的問題。
HAProxy:
1. 支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機；
2. 能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作
3. 支持url檢測後端的服務器出問題的檢測會有很好的幫助。
4. 更多的負載均衡策略比如：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現
5. 單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。
6. HAProxy可以對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。
7. 支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie）
8. 不能做Web服務器即Cache。
三大主流軟件負載均衡器適用業務場景：
1. 網站建設初期，可以選用Nginx、HAProxy作為反向代理負載均衡(流量不大時，可以不選用負載均衡)，因為其配置簡單，性能也能滿足一般業務場景。如果考慮到負載均衡器是有單點問題，可以采用Nginx+Keepalived/HAproxy+Keepalived避免負載均衡器自身的單點問題。
2. 網站並發到達一定程度後，為了提高穩定性和轉發效率，可以使用lvs，畢竟lvs比Nginx/HAProxy要更穩定，轉發效率也更高。
註：nginx與HAProxy比較：nginx只支持七層，用戶量最大，穩定性比較可靠。Haproxy支持四層和七層，支持更多的負載均衡算法，支持session等。
衡量負載均衡器好壞的幾個重要的因素：
1. 會話率 ：單位時間內的處理的請求數
2. 會話並發能力：並發處理能力
3. 數據率：處理數據能力
LVS:
1. 抗負載能力強，性能高，能達到F5的60%，對內存和CPU資源消耗比較低
2. 工作在網絡4層，通過VRRP協議(僅作代理之用)，具體的流量是由linux內核來處理，因此沒有流量的產生。
3. 穩定，可靠性高，自身有完美的熱備方案(Keepalived+lvs)
4. 不支持正則處理，不能做動靜分離。
5. 支持多種負載均衡算法：rr(輪詢)，wrr(帶權輪詢)、lc(最小連接)、wlc(帶權最小連接)
6. 配置相對復雜，對網絡依賴比較大，穩定性很高。
7. LVS工作模式有4種：
(1) nat 地址轉換
(2) dr 直接路由
(4) full-nat
Nginx:
1. 工作在網絡7層，可以針對http應用做一些分流的策略，比如針對域名，目錄結構
2. Nginx對網絡的依賴較小，理論上能ping通就能進行負載功能
3. Nginx安裝配置比較簡單，測試起來很方便
4. 也可以承擔較高的負載壓力且穩定，nginx是為解決c10k問題而誕生的
5. 對後端服務器的健康檢查，只支持通過端口來檢測，不支持通過url來檢測
6. Nginx對請求的異步處理可以幫助節點服務器減輕負載壓力
7. Nginx僅能支持http、https和Email協議，這樣就在適用範圍較小。
9. Nginx還能做Web服務器即Cache功能。
第6點補充：
什麽是nginx的異步處理：
squid同步處理：瀏覽器發起請求，而後請求會立刻被轉到後端，於是在瀏覽器和後臺之間就建立了一個通道。從請求發起直到請求完成，這條通道都是一直存在的。
nginx異步處理：瀏覽器發起請求，請求不會立刻轉到後端，而是請求數據(header)先收到nignx上，然後nginx再把這個請求發到後端，後端處理完成後把數據返回到nginx上，nginx將數據流發到瀏覽器。
使用異步處理的好處：
1. 假設用戶執行一個上傳文件操作，因為用戶網速又比較慢，因此需要花半個小時才能把文件傳到服務器。squid的同步代理在用戶開始上傳後就和後臺建立了連接，半小時後文件上傳結束，由此可見，後臺服務器連接保持了半個小時；而nginx異步代理就是先將此文件收到nginx上，因此僅僅是nginx和用戶保持了半小時連接，後臺服務器在這半小時內沒有為這個請求開啟連接，半小時後用戶上傳結束，nginx才將上傳內容發到後臺，nginx和後臺之間的帶寬是很充裕的，所以只花了一秒鐘就將請求發送到了後臺，由此可見，後臺服務器連接保持了一秒。同步傳輸花了後臺服務器半個小時，異步傳輸只花一秒，可見優化 程度很大。
2. 在上面這個例子中，假如後臺服務器因為種種原因重啟了，上傳文件就自然中斷了，這對用戶來說是非常惱火的一件事情，想必各位也有上傳文件傳到一半被中斷的 經歷。用nginx代理之後，後臺服務器的重啟對用戶上傳的影響減少到了極點，而nginx是非常穩定的並不需要常去重啟它，即使需要重啟，利用kill -HUP就可以做到不間斷重啟nginx。
3. 異步傳輸可以令負載均衡器更有保障，為什麽這麽說呢？在其它的均衡器（lvs/haproxy/apache等）裏，每個請求都是只有一次機會的，假如用 戶發起一個請求，結果該請求分到的後臺服務器剛好掛掉了，那麽這個請求就失敗了；而nginx因為是異步的，所以這個請求可以重新發往下一個後臺，下一個 後臺返回了正常的數據，於是這個請求就能成功了。還是用用戶上傳文件這個例子，假如不但用了nginx代理，而且用了負載均衡，nginx把上傳文件發往 其中一臺後臺，但這臺服務器突然重啟了，nginx收到錯誤後，會將這個上傳文件發到另一臺後臺，於是用戶就不用再花半小時上傳一遍。
4. 假如用戶上傳一個10GB大小的文件，而後臺服務器沒有考慮到這個情況，那麽後臺服務器豈不要崩潰了。用nginx就可以把這些東西都攔在nginx上，通過nginx的上傳文件大小限制功能來限制，另外nginx性能非常有保障，就放心的讓互聯網上那些另類的用戶和nginx對抗去吧。
用異步傳輸會造成問題：
後臺服務器有提供上傳進度的功能的話，用了nginx代理就無法取得進度，這個需要使用nginx的一個第三方模塊來實現。
第8點補充：
Nginx upstream支持的分配策略及原理：
1. 輪詢(默認)：每個請求按照順序逐一分配到不同的後端服務器。如後端服務器down掉，就切換到另一臺並剔除down的後端主機
2. weight：指定輪詢幾率，weight和訪問比率成正比，用於後端服務器性能不均的情況。
3. ip_hash：每個請求按照訪問ip的hash結果分配，不同ip的請求被分配到後端不同的服務器上，可以解決session的問題。
HAProxy:
1. 支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機；
2. 能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作
3. 支持url檢測後端的服務器出問題的檢測會有很好的幫助。
4. 更多的負載均衡策略比如：動態加權輪循(Dynamic Round Robin)，加權源地址哈希(Weighted Source Hash)，加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現
5. 單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。
6. HAProxy可以對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。
7. 支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie）
8. 不能做Web服務器即Cache。
三大主流軟件負載均衡器適用業務場景：
1. 網站建設初期，可以選用Nginx、HAProxy作為反向代理負載均衡(流量不大時，可以不選用負載均衡)，因為其配置簡單，性能也能滿足一般業務場景。如果考慮到負載均衡器是有單點問題，可以采用Nginx+Keepalived/HAproxy+Keepalived避免負載均衡器自身的單點問題。
2. 網站並發到達一定程度後，為了提高穩定性和轉發效率，可以使用lvs，畢竟lvs比Nginx/HAProxy要更穩定，轉發效率也更高。
註：nginx與HAProxy比較：nginx只支持七層，用戶量最大，穩定性比較可靠。Haproxy支持四層和七層，支持更多的負載均衡算法，支持session等。
衡量負載均衡器好壞的幾個重要的因素：
1. 會話率 ：單位時間內的處理的請求數
2. 會話並發能力：並發處理能力
3. 數據率：處理數據能力
三大主流軟件負載均衡器對比(LVS、Nginx、HAproxy)