LVS:
1. 抗負載能力強，性能高学赛，能達到F5的60%，對內(nèi)存和CPU資源消耗比較低
2. 工作在網(wǎng)絡4層吞杭，通過VRRP協(xié)議(僅作代理之用)盏浇，具體的流量是由linux內(nèi)核來處理，因此沒有流量的產(chǎn)生芽狗。
3. 穩(wěn)定绢掰，可靠性高，自身有完美的熱備方案(Keepalived+lvs)
4. 不支持正則處理，不能做動靜分離滴劲。
5. 支持多種負載均衡算法：rr(輪詢)攻晒，wrr(帶權(quán)輪詢)、lc(最小連接)班挖、wlc(帶權(quán)最小連接)
6. 配置相對復雜鲁捏，對網(wǎng)絡依賴比較大，穩(wěn)定性很高萧芙。
7. LVS工作模式有4種：
? ? (1) nat 地址轉(zhuǎn)換
? ? (2) dr 直接路由
? ? (3) tun 隧道
? ? (4) full-nat
Nginx:
1. 工作在網(wǎng)絡7層给梅，可以針對http應用做一些分流的策略，比如針對域名双揪，目錄結(jié)構(gòu)
2. Nginx對網(wǎng)絡的依賴較小动羽，理論上能ping通就能進行負載功能
3. Nginx安裝配置比較簡單，測試起來很方便
4. 也可以承擔較高的負載壓力且穩(wěn)定渔期，nginx是為解決c10k問題而誕生的
5. 對后端服務器的健康檢查运吓，只支持通過端口來檢測，不支持通過url來檢測
6. Nginx對請求的異步處理可以幫助節(jié)點服務器減輕負載壓力
7. Nginx僅能支持http疯趟、https和Email協(xié)議拘哨，這樣就在適用范圍較小。
8. 不支持Session的直接保持迅办，但能通過ip_hash來解決宅静。對Big request header的支持不是很好。
9. Nginx還能做Web服務器即Cache功能站欺。
第6點補充：
1.什么是nginx的異步處理：
squid同步處理：瀏覽器發(fā)起請求姨夹，而后請求會立刻被轉(zhuǎn)到后端，于是在瀏覽器和> 后臺之間就建立了一個通道矾策。從請求發(fā)起直到請求完成磷账，這條通道都是一直存在的。
2.nginx異步處理：
瀏覽器發(fā)起請求贾虽，請求不會立刻轉(zhuǎn)到后端逃糟，而是請求數(shù)據(jù)(header)先收到nignx上，然后nginx再把這個請求發(fā)到后端蓬豁，后端處理完成后把數(shù)據(jù)返回到nginx上绰咽，nginx將數(shù)據(jù)流發(fā)到瀏覽器。
使用異步處理的好處
1.假設(shè)用戶執(zhí)行一個上傳文件操作地粪，因為用戶網(wǎng)速又比較慢取募，因此需要花半個小時才能把文件傳到服務器。squid的同步代理在用戶開始上傳后就和后臺建立了連接蟆技，半小時后文件上傳結(jié)束玩敏，由此可見斗忌，后臺服務器連接保持了半個小時；而nginx異步代理就是先將此文件收到nginx上旺聚，因此僅僅是nginx和用戶保持了半小時連接织阳，后臺服務器在這半小時內(nèi)沒有為這個請求開啟連接，半小時后用戶上傳結(jié)束砰粹，nginx才將上傳內(nèi)容發(fā)到后臺唧躲，nginx和后臺之間的帶寬是很充裕的，所以只花了一秒鐘就將請求發(fā)送到了后臺伸眶，由此可見惊窖，后臺服務器連接保持了一秒。同步傳輸花了后臺服務器半個小時厘贼，異步傳輸只花一秒界酒，可見優(yōu)化程度很大。
2.在上面這個例子中嘴秸，假如后臺服務器因為種種原因重啟了毁欣，上傳文件就自然中斷了，這對用戶來說是非常惱火的一件事情岳掐，想必各位也有上傳文件傳到一半被中斷的經(jīng)歷凭疮。用nginx代理之后，后臺服務器的重啟對用戶上傳的影響減少到了極點串述，而nginx是非常穩(wěn)定的并不需要常去重啟它执解，即使需要重啟，利用kill-HUP就可以做到不間斷重啟nginx纲酗。
3.異步傳輸可以令負載均衡器更有保障衰腌，為什么這么說呢？在其它的均衡器（lvs/haproxy/apache等）里觅赊，每個請求都是只有一次機會的右蕊，假如用戶發(fā)起一個請求，結(jié)果該請求分到的后臺服務器剛好掛掉了吮螺，那么這個請求就失敗了饶囚；而nginx因為是異步的，所以這個請求可以重新發(fā)往下一個后臺鸠补，下一個后臺返回了正常的數(shù)據(jù)萝风，于是這個請求就能成功了。還是用用戶上傳文件這個例子紫岩，假如不但用了nginx代理闹丐，而且用了負載均衡，nginx把上傳文件發(fā)往其中一臺后臺被因，但這臺服務器突然重啟了卿拴，nginx收到錯誤后，會將這個上傳文件發(fā)到另一臺后臺梨与，于是用戶就不用再花半小時上傳一遍堕花。
4.假如用戶上傳一個10GB大小的文件，而后臺服務器沒有考慮到這個情況粥鞋，那么后臺服務器豈不要崩潰了缘挽。用nginx就可以把這些東西都攔在nginx上，通過nginx的上傳文件大小限制功能來限制呻粹，另外nginx性能非常有保障壕曼，就放心的讓互聯(lián)網(wǎng)上那些另類的用戶和nginx對抗去吧。用異步傳輸會造成問題：后臺服務器有提供上傳進度的功能的話等浊，用了nginx代理就無法取得進度腮郊，這個需要使用nginx的一個第三方模塊來實現(xiàn)。
第8點補充：
Nginx upstream支持的分配策略及原理：
1. 輪詢(默認)：每個請求按照順序逐一分配到不同的后端服務器筹燕。如后端服務器down掉轧飞，就切換到另一臺并剔除down的后端主機
2. weight：指定輪詢幾率，weight和訪問比率成正比撒踪，用于后端服務器性能不均的情況过咬。
3. ip_hash：每個請求按照訪問ip的hash結(jié)果分配，不同ip的請求被分配到后端不同的服務器上制妄，可以解決session的問題掸绞。
HAProxy:
1.支持兩種代理模式：TCP（四層）和HTTP（七層），支持虛擬主機耕捞；
2.能夠補充Nginx的一些缺點比如Session的保持衔掸，Cookie的引導等工作
3.支持url檢測后端的服務器出問題的檢測會有很好的幫助。
4.更多的負載均衡策略比如：動態(tài)加權(quán)輪循(DynamicRoundRobin)砸脊，加權(quán)源地址哈希(Weighted SourceHash)具篇，加權(quán)URL哈希和加權(quán)參數(shù)哈希(WeightedParameterHash)已經(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服務器即Cache孩哑。
三大主流軟件負載均衡器適用業(yè)務場景：
? ? 1. 網(wǎng)站建設(shè)初期栓霜，可以選用Nginx、HAProxy作為反向代理負載均衡(流量不大時横蜒，可以不選用負載均衡)胳蛮，因為其配置簡單销凑，性能也能滿足一般業(yè)務場景。如果考慮到負載均衡器是有單點問題仅炊，可以采用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ù)能力
