系統原理分析架構-六-負載均衡(定義及介紹及LVS/Nginx/Haproxy比較)

負載均衡定義:
負載均衡是由多臺服務器以對稱的方式組成一個服務器集合,每臺服務器都 具備等價的地位,均可以單獨對外提供服務而無須其餘服務器的輔助。經過某 種負載分擔技術,將外部發送來的請求均勻分配到對稱結構中的某一臺服務器 上,而接收到請求的服務器獨立地迴應客戶的請求。 均衡負載可以平均分配客戶請求到服務器列陣,籍此提供快速獲取重要數據, 解決大量併發訪問服務問題。這種 羣集技術 能夠用最少的投資得到接近於大型 主機的性能。這種技術能夠運用在流量擁塞時、訪問路徑過長、網民數量大增、運行這種系統負載、大大的提升了系統的可靠性、負載均衡技術解決網絡擁塞的問題、處理大量併發的訪問服務能力、提升服務器的響應速度、爲用戶提供更好的訪問質量。因此說負載均衡是智能化、高性能、靈活性的技術。

設計思想:
一臺普通服務器的處理能力只能達到每秒幾萬個到幾十萬個請求,沒法在一秒鐘內處理上百萬個甚至更多的請求。但若能將多臺這樣的服務器組成一個系統,並經過相關技術將全部請求平均分配給全部服務器,那麼這個系統就徹底擁有每秒鐘處理幾百萬個甚至更多請求的能力。這就是 負載均衡 最初的基本設計思想。

負載均衡的幾種實現技術:
http重定向: 當http代理(好比瀏覽器)向web服務器請求某個URL後,web服務器能夠經過http響應頭信息中的Location標記來返回一個新的URL。這意味着HTTP代理須要繼續請求這個新的URL,完成自動跳轉。

DNS負載均衡 這也是最先的負載均衡技術。在DNS負載均衡服務器中能夠爲不一樣的地址用同一個名字、對於一個名字不一樣的客戶訪問不一樣的WEB服務器獲得其中一個地址、從而達到負載均衡的目的。DNS負載均衡不能區分服務器的區別。


代理負載均衡 :普通用戶訪問Web服務時(其實訪問的是反向代理負載均衡器),反向代理負載均衡器,再 將請求轉發給內部多臺Web服務器,這樣講外部訪問請求根據配置策略負載到內部的多臺Web服務器,從而達到負載均衡的目的。


內部地址外部地址轉換負載均衡 將外部的IP地址映射到多個內部地址、地址轉換網管將每一個鏈接均勻轉換不一樣的內部服務器地址、而後外部計算機就各自與本身轉換獲得的地址的服務器進行鏈接達到負載分擔的目的。


硬件負載均衡: 例如F五、思科會有硬件負載均衡器,來處理請求負載。不過價格相對昂貴。


四層VS七層負載均衡:

       ① 所謂四層就是基於IP+端口的負載均衡;七層就是基於URL等應用層信息的負載均衡;同理,還有基於MAC地址的二層負載均衡和基於IP地址的三層負載均衡。 換句換說,二層負載均衡會經過一個虛擬MAC地址接收請求,而後再分配到真實的MAC地址;三層負載均衡會經過一個虛擬IP地址接收請求,而後再分配到真實的IP地址;四層經過虛擬IP+端口接收請求,而後再分配到真實的服務器;七層經過虛擬的URL或主機名接收請求,而後再分配到真實的服務器。linux

② 所謂的四到七層負載均衡,就是在對後臺的服務器進行負載均衡時,依據四層的信息或七層的信息來決定怎麼樣轉發流量。 好比四層的負載均衡,就是經過發佈三層的IP地址(VIP),而後加四層的端口號,來決定哪些流量須要作負載均衡,對須要處理的流量進行NAT處理,轉發至後臺服務器,並記錄下這個TCP或者UDP的流量是由哪臺服務器處理的,後續這個鏈接的全部流量都一樣轉發到同一臺服務器處理。七層的負載均衡,就是在四層的基礎上(沒有四層是絕對不可能有七層的),再考慮應用層的特徵,好比同一個Web服務器的負載均衡,除了根據VIP加80端口辨別是否須要處理的流量,還可根據七層的URL、瀏覽器類別、語言來決定是否要進行負載均衡。舉個例子,若是你的Web服務器分紅兩組,一組是中文語言的,一組是英文語言的,那麼七層負載均衡就能夠當用戶來訪問你的域名時,自動辨別用戶語言,而後選擇對應的語言服務器組進行負載均衡處理。web

③ 負載均衡器一般稱爲四層交換機或七層交換機。四層交換機主要分析IP層及TCP/UDP層,實現四層流量負載均衡。七層交換機除了支持四層負載均衡之外,還有分析應用層的信息,如HTTP協議URI或Cookie信息。算法


三大主流軟件負載均衡器對比(LVS VS Nginx VS Haproxy)

LVS:
一、抗負載能力強。抗負載能力強、性能高,能達到F5硬件的60%;對內存和cpu資源消耗比較低
二、工做在網絡4層,經過vrrp協議轉發(僅做分發之用),具體的流量由linux內核處理,所以沒有流量的產生。
二、穩定性、可靠性好,自身有完美的熱備方案;(如:LVS+Keepalived)
三、應用範圍比較廣,能夠對全部應用作負載均衡;
四、不支持正則處理,不能作動靜分離。
五、支持負載均衡算法:rr(輪循)、wrr(帶權輪循)、lc(最小鏈接)、wlc(權重最小鏈接)
六、配置 複雜,對網絡依賴比較大,穩定性很高。

Ngnix:
一、工做在網絡的7層之上,能夠針對http應用作一些分流的策略,好比針對域名、目錄結構;
二、Nginx對網絡的依賴比較小,理論上能ping通就就能進行負載功能;
三、Nginx安裝和配置比較簡單,測試起來比較方便;
四、也能夠承擔高的負載壓力且穩定,通常能支撐超過1萬次的併發;
五、對後端服務器的健康檢查,只支持經過端口來檢測,不支持經過url來檢測。
六、Nginx對請求的異步處理能夠幫助節點服務器減輕負載;
七、Nginx僅能支持http、https和Email協議,這樣就在適用範圍較小。
八、不支持Session的直接保持,但能經過ip_hash來解決。、對Big request header的支持不是很好,
九、支持負載均衡算法:Round-robin(輪循)、Weight-round-robin(帶權輪循)、Ip-hash(Ip哈希)

HAProxy的特色是:
一、支持兩種代理模式:TCP(四層)和HTTP(七層),支持虛擬主機;
二、可以補充Nginx的一些缺點好比Session的保持,Cookie的引導等工做
三、支持url檢測後端的服務器出問題的檢測會有很好的幫助。
四、更多的負載均衡策略好比:動態加權輪循(Dynamic Round Robin),加權源地址哈希(Weighted Source Hash),加權URL哈希和加權參數哈希(Weighted Parameter Hash)已經實現
五、單純從效率上來說HAProxy更會比Nginx有更出色的負載均衡速度。
六、HAProxy能夠對Mysql進行負載均衡,對後端的DB節點進行檢測和負載均衡。
九、支持負載均衡算法:Round-robin(輪循)、Weight-round-robin(帶權輪循)、source(原地址保持)、RI(請求URL)、rdp-cookie(根據cookie)

三大主流軟件負載均衡器適用業務場景:
一、網站建設初期,能夠選用Nigix/HAproxy做爲反向代理負載均衡(或者流量不大均可以不選用負載均衡),由於其配置簡單,性能也能知足通常的業務場景。若是考慮到負載均衡器是有單點問題,能夠採用Nginx+Keepalived/HAproxy+Keepalived避免負載均衡器自身的單點問題。
二、網站併發達到必定程度以後,爲了提升穩定性和轉發效率,可使用LVS、畢竟LVS比Nginx/HAproxy要更穩定,轉發效率也更高。不過維護LVS對維護人員的要求也會更高,投入成本也更大。

注:Niginx與Haproxy比較:Niginx支持七層、用戶量最大,穩定性比較可靠。Haproxy支持四層和七層,支持更多的負載均衡算法,支持session保存等。具體選型看使用場景,目前來講Haproxy因爲彌補了一些Niginx的缺點用戶量也不斷在提高。


更多關於負載均衡使用實戰,請關注後續博文。
相關文章
相關標籤/搜索