lvs和nginx均可以用做多機負載方案，他們各有優缺點，在生產環境中須要好好分析實際狀況並加以利用。
1、lvs的優點：
1.抗負載能力強，由於lvs工做方式的邏輯是很是簡單的，並且工做再網絡層第4層，僅做請求分發用，沒有流量，因此在效率上基本不須要太過考慮。lvs通常不多出現故障，即便出現故障通常也是其餘地方（如內存、CPU等）出現問題致使lvs出現問題。
2.配置性地，這一般是一大劣勢同時也是一大優點，由於沒有太多的可配置的選項，因此除了增減服務器，並不須要常常去觸碰它，大大減小了人爲出錯的概率。
3.工做穩定，由於其本省抗負載能力很強，因此穩定性高也是瓜熟蒂落的事，另外各類lvs都有完整的雙機熱備方案，因此一點不用擔憂均衡器自己會出什麼問題，節點出現故障的話，lvs會自動判別，因此係統總體式很是穩定的。
4.無流量，lvs僅僅分發請求，而流量並不從它自己出去，因此能夠利用它這點來作一些線路分流之用。沒有流量同時也保住了均衡器的IO性能不會受到大流量的影響。
5.lvs基本上能支持全部應用，由於綠色工做在第4層，因此它能夠對幾乎全部應用作負載均衡，包括http、數據庫、聊天室等。
另外：lvs也不是徹底能判別節點故障的，好比在wlc分配方式下，集羣裏有一個節點沒有配置vip，會使整個集羣不能使用，這時使用wrr分配方式則會丟掉一臺機器。目前這個問題還在進一步測試中。因此用lvs也得多多小心爲妙。
2、nginx和lvs做對比的結果：
1.nginx工做在網絡的第7層，因此它能夠針對http應用自己來作分流策略，好比針對域名、目錄結構等，相比之下lvs並不具有這樣的功能，因此nginx單憑這點能夠利用的場合就遠多於lvs了；但nginx有用的這些功能使其可調整度要高於lvs，因此常常要去觸碰觸碰，由lvs的第2條優勢來看，觸碰多了，人爲出現問題的概率也就會大。
2.nginx對網絡的依賴較小，理論上只要ping得通，網頁訪問正常，nginx就能連得通，nginx同時還能區份內外網，若是是同時擁有內外網的節點，就至關於單機擁有了備份線路；lvs就比較依賴於網絡環境，目前來看服務器在同一網段內而且lvs使用direct方式分流，效果較能獲得保證。另外注意，lvs須要向託管商至少申請多於一個ip來作visual ip，貌似是不能用本省的ip來作VIP的。要作好lvs管理員，確實得跟進學習不少有關網絡通訊方面的知識，就再也不是一個http那麼簡單了。
3.nginx安裝和配置比較簡單，測試起來也很方便，由於它基本能把錯誤用日誌打印出來。lvs的安裝和配置、測試就要花比較長的時間，由於同上所述，lvs對網絡依賴性比較大，不少時候不能配置成功都是由於網絡問題而不是配置問題，出了問題要解決也相應的會麻煩的多。
4.nginx也一樣能承受很高負載且穩定，但負載度很穩定度差lvs還有幾個等級：nginx處理全部流量因此受限於機器IO和配置；自己的bug也仍是難以免的；nginx沒有現成的雙機熱備方案，因此跑在單機上仍是風險比較大，單機上的事情全都很難說。
5.nginx能夠檢測到服務器內部的故障，好比根據服務器處理網頁返回的狀態碼、超時等等，而且會把返回錯誤的請求從新提交到另外一個節點。目前lvs中ldirectd也能支持針對服務器內部的狀況來監控，但lvs的原理使其不能重發請求。重發請求這點，好比用戶正在上傳一個文件，而處理該上傳的節點恰好在上傳過程當中出現故障，nginx會把上傳切到另外一臺服務器從新處理，而lvs就直接斷掉了，若是是上傳一個很大的文件或者很重要的文件的話，用戶可能會所以而惱火。
6.nginx對請求的異步處理能夠幫助節點服務器減輕負載，鍵入使用Apache直接對外服務，那麼出現不少的窄帶連接時Apache服務器將會佔用大量內存而不能釋放，使用多於一個nginx作Apache代理的話，這些窄帶連接會被nginx擋住，Apache上就不會堆積過多的請求，這樣就減小了至關多的內存佔用。這點使用squid也有相同的做用，即便squid自己配置爲不緩存，對Apache仍是有很大幫助你的。lvs沒有這些功能，也就沒法能比較。
7.nginx能支持http和Email（Email的功能估計比較少人用），lvs所支持的應用在這點上會比nginx更過。
在使用上，通常最前端所採起的的策略應是lvs，也就是dns的指向應爲lvs均衡器，lvs的優勢另它很是適合作這個任務。
重要的ip地址，最好交由lvs託管，好比數據庫的ip、webservice服務器的ip等等，這些ip地址隨着時間推移，使用面會愈來愈大，若是更換ip則故障會接踵而來。因此將這些重要ip交給lvs託管式最爲穩妥的，這樣作的惟一缺點是須要VIP數量會比較多。
nginx能夠做爲lvs節點機器使用，一是能夠利用nginx的功能，二是能夠利用nginx的性能。固然這一層面也能夠直接使用squid，squid的功能方面就比nginx弱很多，性能上也有所遜色於nginx。
nginx也能夠做爲中層代理使用，這一層面nginx基本上無對手，惟一能夠撼動nginx的就只有lighttpd了，不過lighttpd目前尚未能作到nginx徹底的功能，配置也不那麼清晰易讀。另外，中層代理的ip也是重要的，因此中層代理業擁有一個VIP和lvs是最完美的方案了。
nginx也能夠做爲網頁靜態服務器。
具體的應用還得具體分析，若是是比較小的網站（日pv<1000萬），用nginx就徹底能夠了，若是機器也很多，能夠用dns輪詢，lvs所耗費的機器仍是比較多的；大型網站或者重要的服務，機器不發愁的時候要多多考慮利用lvs。
說明：
使用nginx+keepalived實現負載均衡，解決單點與高流量併發問題。爲何要用nginx而不用lvs？
7個理由：
1.高併發鏈接：官方測試可以支撐5萬併發鏈接，在實際生產環境中跑到2——3萬併發鏈接數。
2.內存消耗少：在3萬併發鏈接數下，開啓的10個nginx進程才消耗150M內存（150*10=150M）。
3.配置文件很是簡單：風格跟程序同樣通俗易懂。
4.成本低廉：nginx爲開源軟件，能夠無償使用。而購買F5 big-ip、netscaler等硬件負載均衡交換機則須要十多萬至幾十萬人民幣。
（使用nginx作七層負載均衡的理由？）
5.支持rewrite重寫規則：可以根據域名、url的不一樣，將http請求分到不一樣的後端服務器羣組。
6.內置的健康檢查功能：若是nginx proxy後端的某臺web服務器宕機了，不會影響前端訪問。
7.節省帶寬：支持gzip壓縮，能夠添加瀏覽器本地緩存的header頭。
進一步說明：
keepalived是linux下面實現vrrp備份路由的高可靠性運行件。基於keepalived設計的服務模式可以真正作到主服務器和備份服務器故障時ip瞬間無縫交接。
nginx是基於linux2.6內核中epoll模型http服務器，與Apache進程派生模式不一樣的是nginx進程基於master+slave多進程模型，自身具備很是穩定的子進程管理功能。在master進程分配模式下，master進程永遠不進行業務處理，只是進行任務分發，從而達到master進程的存活高可靠性，slave進程全部的業務信號都由主進程發出，slave進城全部的超時任務都會被master終止，屬於阻塞式人物模型。
服務器ip存活檢測是由keepalived本身自己完成的，將2臺服務器配置成keepalived互爲主輔關係，任意一方機器故障對方都可以將ip接管過去。
keepalived的服務器ip經過其配置文件進行管理，依靠其自身的進程去肯定服務器的存活狀態，若是在須要對服務器進程在線維護的狀況下，只須要停掉被維護機器的keepalived服務進程，另一臺服務器就可以接管該臺服務器的全部應用。