lvs(+keepalived)、haproxy(+heartbeat)、nginx 負載均衡的比較分析

目前使用比較多的就是标題中提到的這兩者，其實lvs和haproxy都是實作的負載均衡的作用，keepalived和heartbeat都是提高高可用性的，避免單點故障。那麼他們為什麼這麼搭配，而又有什麼差別呢？

經過一番google，大體明白了兩者的差別：

lvs的是通過vrrp協定進行資料包轉發的，提供的是4層的負載均衡。特點是效率高，隻要你機器網卡抗的住就不是問題。

haproxy可以提供4層或7層的資料轉發服務，能做到7層的好處是可以根據服務所處的狀态等進行負載。

以上兩者隻是實作了負載均衡，但是他們本身是明顯的單點故障，是以需要使用雙機軟體做熱備，來保證高可用性。keepalived可以通過檢測vrrp資料包來切換，是以更适合與lvs搭配。而heartbeat更适于和haproxy搭配。這樣就出現了這兩個應用比較多也比較經典的負載均衡的高可用性方案了。

原來一直想學習下這兩個方案，學會這4個軟體的配置，可又覺得永遠用不到吧？或者用到的時候說不定又出現了新的技術了。就是自己能用到了，反向代理一類的軟體足夠用了，squid偶是實在沒有心情學習了。對nginx的感覺還不錯，性能好是大家公認的，即可以做反向代理實作負載均衡，又通過geo子產品實作流量分離做全局（不同地域）的負載均衡，加上配置簡單，絕對是個人的首選，可以考慮搭配heartbeat實作高可用。

接下來的學習目标就簡化了，nginx的geo和heartbeat的配置。

您可任意轉載,請标明來源：lvs+keepalived和haproxy+heartbeat差別

對軟體實作負載均衡的幾個軟體，小D詳細看了一下，從性能和穩定上還是LVS最牛，基本達到了F5硬體裝置的60%性能，其他幾個10%都有點困難。

不過就因為LVS忒牛了，配置也最麻煩了，而且健康檢測需要另外配置Ldirector，其他HAPROXY和NGINX自己就用，而且配置超級簡單。

是以小D建議，如果網站通路量不是門戶級别的用HAPROXY或者NGINX就OK了，到了門戶級别在用LVS+Idirector吧 哈哈

lvs和nginx都可以用作多機負載的方案，它們各有優缺，在生産環境中需要好好分析實際情況并加以利用。

首先提醒，做技術切不可人雲亦雲，我雲即你雲；同時也不可太趨向保守，過于相信舊有方式而等别人來幫你做墊被測試。把所有即時聽說到的好東西加以鑽研，進而提高自己對技術的認知和水準，乃是一個好習慣。

下面來分析一下兩者：

一、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來做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的優點:

性能好，可以負載超過1萬的并發。

功能多，除了負載均衡，還能作Web伺服器，而且可以通過Geo子產品來實作流量配置設定。

社群活躍，第三方更新檔和子產品很多

支援gzip proxy

缺點:

不支援session保持。

對後端realserver的健康檢查功能效果不好。而且隻支援通過端口來檢測，不支援通過url來檢測。

nginx對big request header的支援不是很好，如果client_header_buffer_size設定的比較小，就會傳回400bad request頁面。

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 request header的支援不是很好，另外預設的隻有Round-robin和IP-hash兩種負載均衡算法。

HAProxy的特點是：

1、HAProxy是工作在網絡7層之上。

2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作

3、支援url檢測後端的伺服器出問題的檢測會有很好的幫助。

4、更多的負載均衡政策比如：動态權重輪循(Dynamic Round Robin)，權重源位址哈希(Weighted Source Hash)，權重URL哈希和權重參數哈希(Weighted Parameter Hash)已經實作

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

6、HAProxy可以對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡。

***********************************************************************************************

現在網站發展的趨勢對網絡負載均衡的使用是随着網站規模的提升根據不同的階段來使用不同的技術：

第一階段：利用Nginx或者HAProxy進行單點的負載均衡，這一階段伺服器規模剛脫離開單伺服器、單資料庫的模式，需要一定的負載均衡，但是 仍然規模較小沒有專業的維護團隊來進行維護，也沒有需要進行大規模的網站部署。這樣利用Nginx或者HAproxy就是第一選擇，此時這些東西上手快， 配置容易，在七層之上利用HTTP協定就可以。這時是第一選擇

第二階段：随着網絡服務進一步擴大，這時單點的Nginx已經不能滿足，這時使用LVS或者商用F5就是首要選擇，Nginx此時就作為LVS或者 F5的節點來使用，具體LVS或者F5的是選擇是根據公司規模，人才以及資金能力來選擇的，這裡也不做詳談，但是一般來說這階段相關人才跟不上業務的提 升，是以購買商業負載均衡已經成為了必經之路。

第三階段：這時網絡服務已經成為主流産品，此時随着公司知名度也進一步擴充，相關人才的能力以及數量也随之提升，這時無論從開發适合自身産品的定制，以及降低成本來講開源的LVS，已經成為首選，這時LVS會成為主流。

最終形成比較理想的狀态為：F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。