一、lvs的優勢：
1、抗負載能力強，因為lvs工作方式的邏輯是非常之簡單，而且工作在網路4層僅做請求分發之用，沒有流量，所以在效率上基本不需要太過考慮。在我手裡的lvs，僅僅出過一次問題：在併發最高的一小段時間內均衡器出現丟包現象，據分析為網路問題，即網絡卡或linux2.4核心的承載能力已到上限，記憶體和
cpu方面基本無消耗。
2、配置性低，這通常是一大劣勢，但同時也是一大優勢，因為沒有太多可配置的選項，所以除了增減伺服器，並不需要經常去觸碰它，大大減少了人為出錯的機率。
3、工作穩定，因為其本身抗負載能力很強，所以穩定性高也是順理成章，另外各種lvs都有完整的雙機熱備方案，所以一點不用擔心均衡器本身會出什麼問題，節點出現故障的話，lvs會自動判別，所以系統整體是非常穩定的。
4、無流量，上面已經有所提及了。lvs僅僅分發請求，而流量並不從它本身出去，所以可以利用它這點來做一些線路分流之用。沒有流量同時也保住了均衡器的io效能不會受到大流量的影響。
5、基本上能支援所有應用，因為lvs工作在4層，所以它可以對幾乎所有應用做負載均衡，包括http、資料庫、聊天室等等。
另：lvs也不是完全能判別節點故障的，譬如在wlc分配方式下，集群
裡有乙個節點沒有配置vip，會使整個集群不能使用，這時使用wrr分配方式則會丟掉一台機。目前這個問題還在進一步測試中。所以，用lvs也得多多當心為妙。
二、nginx和lvs作對比的結果
1、nginx工作在網路的7層，所以它可以針對http應用本身來做分流策略，比如針對網域名稱、目錄結構等，相比之下lvs並不具備這樣的功能，所以nginx單憑這點可利用的場合就遠多於lvs了；但nginx有用的這些功能使其可調整度要高於lvs，所以經常要去觸碰觸碰，由lvs的第2條優點看，觸碰多了，人為出問題的機率也就會大。
2、nginx對網路的依賴較小，理論上只要ping
得通，網頁訪問正常，nginx就能連得通，nginx同時還能區分內外網，如果是同時擁有內外網的節點，就相當於單機擁有了備份線路；lvs就比較依賴於網路環境，目前來看伺服器在同一網段內並且lvs使用direct方式分流，效果較能得到保證。另外注意，lvs需要向託管商至少申請多乙個ip來做visu
alip，貌似是不能用本身的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的優點:
效能好，可以負載超過1萬的併發。
功能多，除了負載均衡，還能作web伺服器，而且可以通過geo模組來實現流量分配。
社群活躍，第三方補丁和模組很多
支援gzip
proxy
缺點:不支援session保持。
對後端reals
erver的健康檢查功能效果不好。而且只支援通過埠來檢測，不支援通過url來檢測。
nginx對big requestheader的支援不是很好，如果client_header_buffer_size設定的比較小，就會返回400badrequest頁面。
haproxy的優點:
它的優點正好可以補充nginx的缺點。支援session保持，同時支援通過獲取指定的url來檢測後端伺服器的狀態。
支援tcp模式的負載均衡。比如可以給mysql的從伺服器集群和郵件伺服器做負載均衡。
缺點：不支援虛擬主機(這個很傻啊)
目前沒有nagios和cacti的效能監控模板
lvs的優點:
效能好，接近硬體裝置的網路吞吐和連線負載能力。
lvs的dr模式，支援通過廣域網進行負載均衡。這個其他任何負載均衡軟體目前都不具備。
缺點：比較重型。另外社群不如nginx活躍。
現在網路中常見的的負載均衡主要分為兩種：一種是通過硬體來進行進行，常見的硬體有比較昂貴的netscaler、f5、radware和array等商用的負載均衡器，也有類似於lvs、nginx、haproxy的基於linux的開源的負載均衡策略,
商用負載均衡裡面netscaler從效果上比f5的效率上更高。對於負載均衡器來說，不過商用負載均衡由於可以建立在四~七層協議之上，因此適用面更廣所以有其不可替代性，他的優點就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大，所以對於規模較小的網路服務來說暫時還沒有需要使用。
另一種負載均衡的方式是通過軟體：比較常見的有lvs、nginx、haproxy等，其中lvs是建立在四層協議上面的，而另外nginx和haproxy是建立在七層協議之上的，下面分別介紹關於
lvs：使用集群技術和linux作業系統實現乙個高效能、高可用的伺服器，它具有很好的可伸縮性（scalability）、可靠性（reliability）和可管理性（manageability）。
lvs的特點是：
1、抗負載能力強、是工作在網路4層之上僅作分發之用，沒有流量的產生；
2、配置性比較低，這是乙個缺點也是乙個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的機率；
3、工作穩定，自身有完整的雙機熱備方案；
4、無流量，保證了均衡器io的效能不會收到大流量的影響；
5、應用範圍比較廣，可以對所有應用做負載均衡；
6、lvs需要向idc多申請乙個ip來做visual ip，因此需要一定的網路知識，所以對操作人的要求比較高。
nginx的特點是：
1、工作在網路的7層之上，可以針對http應用做一些分流的策略，比如針對網域名稱、目錄結構；
2、nginx對網路的依賴比較小；
3、nginx安裝和配置比較簡單，測試起來比較方便；
4、也可以承擔高的負載壓力且穩定，一般能支撐超過1萬次的併發；
5、nginx可以通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等，並且會把返回錯誤的請求重新提交到另乙個節點，不過其中缺點就是不支援url來檢測；
6、nginx對請求的非同步處理可以幫助節點伺服器減輕負載；
7、nginx能支援http和email，這樣就在適用範圍上面小很多；
8、不支援session的保持、對big requestheader的支援不是很好，另外預設的只有round-robin和ip-hash兩種負載均衡演算法。
haproxy的特點是：
1、haproxy是工作在網路7層之上。
2、能夠補充nginx的一些缺點比如session的保持，cookie的引導等工作
3、支援url檢測後端的伺服器出問題的檢測會有很好的幫助。
4、更多的負載均衡策略比如：動態加權輪循(dynamic round robin)，加權源位址雜湊(weightedsource hash)，加權url雜湊和加權引數雜湊(weighted parameter hash)已經實現
5、單純從效率上來講haproxy更會比nginx有更出色的負載均衡速度。
6、haproxy可以對mysql進行負載均衡，對後端的db節點進行檢測和負載均衡。
springcloud（Ribbon負載均衡）
搭建步驟 1.使用者服務的集群 2.訂單服務整合ribbon 2.1.匯入ribbon的依賴 2.2.在resttemplate的bean定義方法上加上 loadbalanced註解 2.3.把訂單的controller向使用者發起呼叫的resttemplate的url使用服務名呼叫，如 http ...
SpringCloud Ribbon 負載均衡
ribbon eureka都是netflix旗下的專案，eureka client內建了ribbon，用於實現負載均衡，預設使用輪詢。輪詢是最簡單的負載均衡演算法，每次呼叫服務拿到節點列表後，從前往後依次輪詢類表中的每個節點，誰空閒就呼叫誰。測試時往往都是呼叫列表的第乙個節點，因為重新整理的手速遠遠...
linux centos nginx做負載均衡
nginx 是 c語言 開發，建議在 linux 上執行，當然，也可以安裝 windows 版本，本篇則使用 centos 7 作為安裝環境。一.gcc 安裝 yum install gcc c 二.pcre pcre devel 安裝pcre perl compatible regular exp...