LVS:

1. 抗負載能力強，性能高，能達到F5的60%，對內(nèi)存和CPU資源消耗比較低

2. 工作在網(wǎng)絡(luò)4層，通過VRRP協(xié)議(僅作代理之用)，具體的流量是由linux內(nèi)核來處理，因此沒有流量的產(chǎn)生。

3. 穩(wěn)定，可靠性高，自身有完美的熱備方案(Keepalived+lvs)

4. 不支持正則處理，不能做動靜分離。

5. 支持多種負載均衡算法：rr(輪詢)，wrr(帶權(quán)輪詢)、lc(最小連接)、wlc(帶權(quán)最小連接)

6. 配置相對復(fù)雜，對網(wǎng)絡(luò)依賴比較大，穩(wěn)定性很高。

7. LVS工作模式有4種：

(1) nat 地址轉(zhuǎn)換

(2) dr 直接路由

(3) tun 隧道

(4) full-nat 

Nginx:

1. 工作在網(wǎng)絡(luò)7層，可以針對http應(yīng)用做一些分流的策略，比如針對域名，目錄結(jié)構(gòu)

2. Nginx對網(wǎng)絡(luò)的依賴較小，理論上能ping通就能進行負載功能

3. Nginx安裝配置比較簡單，測試起來很方便

4. 也可以承擔(dān)較高的負載壓力且穩(wěn)定，nginx是為解決c10k問題而誕生的

5. 對后端服務(wù)器的健康檢查，只支持通過端口來檢測，不支持通過url來檢測

6. Nginx對請求的異步處理可以幫助節(jié)點服務(wù)器減輕負載壓力

7. Nginx僅能支持http、https和Email協(xié)議，這樣就在適用范圍較小。

8. 不支持Session的直接保持，但能通過ip_hash來解決。對Big request header的支持不是很好。

9. Nginx還能做Web服務(wù)器即Cache功能。

第6點補充：

什么是nginx的異步處理：

squid同步處理：瀏覽器發(fā)起請求，而后請求會立刻被轉(zhuǎn)到后端，于是在瀏覽器和后臺之間就建立了一個通道。從請求發(fā)起直到請求完成，這條通道都是一直存在的。

nginx異步處理：瀏覽器發(fā)起請求，請求不會立刻轉(zhuǎn)到后端，而是請求數(shù)據(jù)(header)先收到nignx上，然后nginx再把這個請求發(fā)到后端，后端處理完成后把數(shù)據(jù)返回到nginx上，nginx將數(shù)據(jù)流發(fā)到瀏覽器。

使用異步處理的好處：

1. 假設(shè)用戶執(zhí)行一個上傳文件操作，因為用戶網(wǎng)速又比較慢，因此需要花半個小時才能把文件傳到服務(wù)器。squid的同步代理在用戶開始上傳后就和后臺建立了連接，半小時后文件上傳結(jié)束，由此可見，后臺服務(wù)器連接保持了半個小時；而nginx異步代理就是先將此文件收到nginx上，因此僅僅是nginx和用戶保持了半小時連接，后臺服務(wù)器在這半小時內(nèi)沒有為這個請求開啟連接，半小時后用戶上傳結(jié)束，nginx才將上傳內(nèi)容發(fā)到后臺，nginx和后臺之間的帶寬是很充裕的，所以只花了一秒鐘就將請求發(fā)送到了后臺，由此可見，后臺服務(wù)器連接保持了一秒。同步傳輸花了后臺服務(wù)器半個小時，異步傳輸只花一秒，可見優(yōu)化 程度很大。

2. 在上面這個例子中，假如后臺服務(wù)器因為種種原因重啟了，上傳文件就自然中斷了，這對用戶來說是非常惱火的一件事情，想必各位也有上傳文件傳到一半被中斷的 經(jīng)歷。用nginx代理之后，后臺服務(wù)器的重啟對用戶上傳的影響減少到了極點，而nginx是非常穩(wěn)定的并不需要常去重啟它，即使需要重啟，利用kill -HUP就可以做到不間斷重啟nginx。

3. 異步傳輸可以令負載均衡器更有保障，為什么這么說呢？在其它的均衡器（lvs/haproxy/apache等）里，每個請求都是只有一次機會的，假如用 戶發(fā)起一個請求，結(jié)果該請求分到的后臺服務(wù)器剛好掛掉了，那么這個請求就失敗了；而nginx因為是異步的，所以這個請求可以重新發(fā)往下一個后臺，下一個 后臺返回了正常的數(shù)據(jù)，于是這個請求就能成功了。還是用用戶上傳文件這個例子，假如不但用了nginx代理，而且用了負載均衡，nginx把上傳文件發(fā)往 其中一臺后臺，但這臺服務(wù)器突然重啟了，nginx收到錯誤后，會將這個上傳文件發(fā)到另一臺后臺，于是用戶就不用再花半小時上傳一遍。

4. 假如用戶上傳一個10GB大小的文件，而后臺服務(wù)器沒有考慮到這個情況，那么后臺服務(wù)器豈不要崩潰了。用nginx就可以把這些東西都攔在nginx上，通過nginx的上傳文件大小限制功能來限制，另外nginx性能非常有保障，就放心的讓互聯(lián)網(wǎng)上那些另類的用戶和nginx對抗去吧。

用異步傳輸會造成問題：

后臺服務(wù)器有提供上傳進度的功能的話，用了nginx代理就無法取得進度，這個需要使用nginx的一個第三方模塊來實現(xiàn)。

第8點補充：

Nginx upstream支持的分配策略及原理：

1. 輪詢(默認)：每個請求按照順序逐一分配到不同的后端服務(wù)器。如后端服務(wù)器down掉，就切換到另一臺并剔除down的后端主機

2. weight：指定輪詢幾率，weight和訪問比率成正比，用于后端服務(wù)器性能不均的情況。

3. ip_hash：每個請求按照訪問ip的hash結(jié)果分配，不同ip的請求被分配到后端不同的服務(wù)器上，可以解決session的問題。

HAProxy:

1. 支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機；

2. 能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導(dǎo)等工作

3. 支持url檢測后端的服務(wù)器出問題的檢測會有很好的幫助。

4. 更多的負載均衡策略比如：動態(tài)加權(quán)輪循(Dynamic Round Robin)，加權(quán)源地址哈希(Weighted Source Hash)，加權(quán)URL哈希和加權(quán)參數(shù)哈希(Weighted Parameter Hash)已經(jīng)實現(xiàn)

5. 單純從效率上來講HAProxy更會比Nginx有更出色的負載均衡速度。

6. HAProxy可以對Mysql進行負載均衡，對后端的DB節(jié)點進行檢測和負載均衡。

7. 支持負載均衡算法：Round-robin（輪循）、Weight-round-robin（帶權(quán)輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據(jù)cookie）

8. 不能做Web服務(wù)器即Cache。

三大主流軟件負載均衡器適用業(yè)務(wù)場景：

1. 網(wǎng)站建設(shè)初期，可以選用Nginx、HAProxy作為反向代理負載均衡(流量不大時，可以不選用負載均衡)，因為其配置簡單，性能也能滿足一般業(yè)務(wù)場景。如果考慮到負載均衡器是有單點問題，可以采用Nginx+Keepalived/HAproxy+Keepalived避免負載均衡器自身的單點問題。

2. 網(wǎng)站并發(fā)到達一定程度后，為了提高穩(wěn)定性和轉(zhuǎn)發(fā)效率，可以使用lvs，畢竟lvs比Nginx/HAProxy要更穩(wěn)定，轉(zhuǎn)發(fā)效率也更高。

注：nginx與HAProxy比較：nginx只支持七層，用戶量最大，穩(wěn)定性比較可靠。Haproxy支持四層和七層，支持更多的負載均衡算法，支持session等。

衡量負載均衡器好壞的幾個重要的因素：

1. 會話率 ：單位時間內(nèi)的處理的請求數(shù)

2. 會話并發(fā)能力：并發(fā)處理能力

3. 數(shù)據(jù)率：處理數(shù)據(jù)能力