如今網絡中常見的的負載均衡主要分爲兩種:一種是經過硬件來進行進行,常見的硬件有比較昂貴的NetScaler、F五、Radware和Array等商用的負載均衡器,也有相似於LVS、Nginx、HAproxy的基於Linux的開源的負載均衡策略,算法
商用負載均衡裏面NetScaler從效果上比F5的效率上更高。對於負載均衡器來講,不過商用負載均衡因爲能夠創建在四~七層協議之上,所以適用 面更廣因此有其不可替代性,他的優勢就是有專業的維護團隊來對這些服務進行維護、缺點就是花銷太大,因此對於規模較小的網絡服務來講暫時尚未須要使用。sql
另外一種負載均衡的方式是經過軟件:比較常見的有LVS、Nginx、HAproxy等,其中LVS是創建在四層協議上面的,而另外Nginx和HAproxy是創建在七層協議之上的,下面分別介紹關於數據庫
LVS:使用集羣技術和Linux操做系統實現一個高性能、高可用的服務器,它具備很好的可伸縮性(Scalability)、可靠性(Reliability)和可管理性(Manageability)。後端
LVS的特色是:服務器
一、抗負載能力強、是工做在網絡4層之上僅做分發之用,沒有流量的產生;網絡
二、配置性比較低,這是一個缺點也是一個優勢,由於沒有可太多配置的東西,因此並不須要太多接觸,大大減小了人爲出錯的概率;併發
三、工做穩定,自身有完整的雙機熱備方案;負載均衡
四、無流量,保證了均衡器IO的性能不會收到大流量的影響;異步
五、應用範圍比較廣,能夠對全部應用作負載均衡;性能
六、LVS須要向IDC多申請一個IP來作Visual IP,所以須要必定的網絡知識,因此對操做人的要求比較高。
Nginx的特色是:
一、工做在網絡的7層之上,能夠針對http應用作一些分流的策略,好比針對域名、目錄結構;
二、Nginx對網絡的依賴比較小;
三、Nginx安裝和配置比較簡單,測試起來比較方便;
四、也能夠承擔高的負載壓力且穩定,通常能支撐超過1萬次的併發;
五、Nginx能夠經過端口檢測到服務器內部的故障,好比根據服務器處理網頁返回的狀態碼、超時等等,而且會把返回錯誤的請求從新提交到另外一個節點,不過其中缺點就是不支持url來檢測;
六、Nginx對請求的異步處理能夠幫助節點服務器減輕負載;
七、Nginx能支持http和Email,這樣就在適用範圍上面小不少;
八、不支持Session的保持、對Big request header的支持不是很好,另外默認的只有Round-robin和IP-hash兩種負載均衡算法。
HAProxy的特色是:
一、HAProxy是工做在網絡7層之上。
二、可以補充Nginx的一些缺點好比Session的保持,Cookie的引導等工做
三、支持url檢測後端的服務器出問題的檢測會有很好的幫助。
四、更多的負載均衡策略好比:動態加權輪循(Dynamic Round Robin),加權源地址哈希(Weighted Source Hash),加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現
五、單純從效率上來說HAProxy更會比Nginx有更出色的負載均衡速度。
六、HAProxy能夠對Mysql進行負載均衡,對後端的DB節點進行檢測和負載均衡。
***********************************************************************************************
如今網站發展的趨勢對網絡負載均衡的使用是隨着網站規模的提高根據不一樣的階段來使用不一樣的技術:
第一階段:利用Nginx或者HAProxy進行單點的負載均衡,這一階段服務器規模剛脫離開單服務器、單數據庫的模式,須要必定的負載均衡,可是 仍然規模較小沒有專業的維護團隊來進行維護,也沒有須要進行大規模的網站部署。這樣利用Nginx或者HAproxy就是第一選擇,此時這些東西上手快, 配置容易,在七層之上利用HTTP協議就能夠。這時是第一選擇
第二階段:隨着網絡服務進一步擴大,這時單點的Nginx已經不能知足,這時使用LVS或者商用F5就是首要選擇,Nginx此時就做爲LVS或者 F5的節點來使用,具體LVS或者F5的是選擇是根據公司規模,人才以及資金能力來選擇的,這裏也不作詳談,可是通常來講這階段相關人才跟不上業務的提 升,因此購買商業負載均衡已經成爲了必經之路。
第三階段:這時網絡服務已經成爲主流產品,此時隨着公司知名度也進一步擴展,相關人才的能力以及數量也隨之提高,這時不管從開發適合自身產品的定製,以及下降成原本講開源的LVS,已經成爲首選,這時LVS會成爲主流。
最終造成比較理想的狀態爲:F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。