什麼是負載均衡？【轉】

http://www.javashuo.com/article/p-qcyqjwoe-dz.html

1、什麼是負載均衡？

互聯網早期，業務流量比較小而且業務邏輯比較簡單，單臺服務器即可以知足基本的需求；但隨着互聯網的發展，業務流量愈來愈大而且業務邏輯也愈來愈複雜，單臺機器的性能問題以及單點問題凸顯了出來，所以須要多臺機器來進行性能的水平擴展以及避免單點故障。可是要如何將不一樣的用戶的流量分發到不一樣的服務器上面呢？

 

 早期的方法是使用DNS作負載，經過給客戶端解析不一樣的IP地址，讓客戶端的流量直接到達各個服務器。可是這種方法有一個很大的缺點就是延時性問題，在作出調度策略改變之後，因爲DNS各級節點的緩存並不會及時的在客戶端生效，並且DNS負載的調度策略比較簡單，沒法知足業務需求，所以就出現了負載均衡。

客戶端的流量首先會到達負載均衡服務器，由負載均衡服務器經過必定的調度算法將流量分發到不一樣的應用服務器上面，同時負載均衡服務器也會對應用服務器作週期性的健康檢查，當發現故障節點時便動態的將節點從應用服務器集羣中剔除，以此來保證應用的高可用。

　負載均衡又分爲四層負載均衡和七層負載均衡。四層負載均衡工做在OSI模型的傳輸層，主要工做是轉發，它在接收到客戶端的流量之後經過修改數據包的地址信息將流量轉發到應用服務器。

　七層負載均衡工做在OSI模型的應用層，由於它須要解析應用層流量，因此七層負載均衡在接到客戶端的流量之後，還須要一個完整的TCP/IP協議棧。七層負載均衡會與客戶端創建一條完整的鏈接並將應用層的請求流量解析出來，再按照調度算法選擇一個應用服務器，並與應用服務器創建另一條鏈接將請求發送過去，所以七層負載均衡的主要工做就是代理。

 

2、四層和七層負載均衡的區別？

2.1 - 技術原理上的區別。

　所謂四層負載均衡，也就是主要經過報文中的目標地址和端口，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。

　以常見的TCP爲例，負載均衡設備在接收到第一個來自客戶端的SYN 請求時，即經過上述方式選擇一個最佳的服務器，並對報文中目標IP地址進行修改(改成後端服務器IP），直接轉發給該服務器。TCP的鏈接創建，即三次握手是客戶端和服務器直接創建的，負載均衡設備只是起到一個相似路由器的轉發動做。在某些部署狀況下，爲保證服務器回包能夠正確返回給負載均衡設備，在轉發報文的同時可能還會對報文原來的源地址進行修改。

　所謂七層負載均衡，也稱爲「內容交換」，也就是主要經過報文中的真正有意義的應用層內容，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。

　以常見的TCP爲例，負載均衡設備若是要根據真正的應用層內容再選擇服務器，只能先代理最終的服務器和客戶端創建鏈接(三次握手)後，纔可能接受到客戶端發送的真正應用層內容的報文，而後再根據該報文中的特定字段，再加上負載均衡設備設置的服務器選擇方式，決定最終選擇的內部服務器。
　
　負載均衡設備在這種狀況下，更相似於一個代理服務器。負載均衡和前端的客戶端以及後端的服務器會分別創建TCP鏈接。因此從這個技術原理上來看，七層負載均衡明顯的對負載均衡設備的要求更高，處理七層的能力也必然會低於四層模式的部署方式。那麼，爲何還須要七層負載均衡呢？

2.2 - 應用場景的需求。

　七層應用負載的好處，是使得整個網絡更"智能化", 參考咱們以前的另一篇專門針對HTTP應用的優化的介紹，就能夠基本上了解這種方式的優點所在。例如訪問一個網站的用戶流量，能夠經過七層的方式，將對圖片類的請求轉發到特定的圖片服務器並可使用緩存技術；將對文字類的請求能夠轉發到特定的文字服務器並可使用壓縮技術。

　固然這只是七層應用的一個小案例，從技術原理上，這種方式能夠對客戶端的請求和服務器的響應進行任意意義上的修改，極大的提高了應用系統在網絡層的靈活性。不少在後臺，(例如Nginx或者Apache)上部署的功能能夠前移到負載均衡設備上，例如客戶請求中的Header重寫，服務器響應中的關鍵字過濾或者內容插入等功能。

　另一個經常被提到功能就是安全性。網絡中最多見的SYN Flood攻擊，即黑客控制衆多源客戶端，使用虛假IP地址對同一目標發送SYN攻擊，一般這種攻擊會大量發送SYN報文，耗盡服務器上的相關資源，以達到Denial of Service(DoS)的目的。

　從技術原理上也能夠看出，四層模式下這些SYN攻擊都會被轉發到後端的服務器上；而七層模式下這些SYN攻擊天然在負載均衡設備上就截止，不會影響後臺服務器的正常運營。另外負載均衡設備能夠在七層層面設定多種策略，過濾特定報文，例如SQL Injection等應用層面的特定攻擊手段，從應用層面進一步提升系統總體安全。

　如今的7層負載均衡，主要仍是着重於應用普遍的HTTP協議，因此其應用範圍主要是衆多的網站或者內部信息平臺等基於B/S開發的系統。 4層負載均衡則對應其餘TCP應用，例如基於C/S開發的ERP等系統。

2.3 - 七層應用須要考慮的問題。

• 是否真的必要，七層應用的確能夠提升流量智能化，同時必不可免的帶來設備配置複雜，負載均衡壓力增高以及故障排查上的複雜性等問題。在設計系統時須要考慮四層七層同時應用的混雜狀況。

• 是否真的能夠提升安全性。例如SYN Flood攻擊，七層模式的確將這些流量從服務器屏蔽，但負載均衡設備自己要有強大的抗DDoS能力，不然即便服務器正常而做爲中樞調度的負載均衡設備故障也會致使整個應用的崩潰。

• 是否有足夠的靈活度。七層應用的優點是可讓整個應用的流量智能化，可是負載均衡設備須要提供完善的七層功能，知足客戶根據不一樣狀況的基於應用的調度。最簡單的一個考覈就是可否取代後臺Nginx或者Apache等服務器上的調度功能。可以提供一個七層應用開發接口的負載均衡設備，可讓客戶根據需求任意設定功能，才真正有可能提供強大的靈活性和智能性。

3、負載均衡的算法？

1. 隨機算法

• Random隨機，按權重設置隨機機率。在一個截面上碰撞的機率高，但調用量越大分佈越均勻，並且按機率使用權重後也比較均勻，有利於動態調整提供者權重。

2. 輪詢及加權輪詢

• 輪詢(Round Robbin)當服務器羣中各服務器的處理能力相同時，且每筆業務處理量差別不大時，最適合使用這種算法。 輪循，按公約後的權重設置輪循比率。存在慢的提供者累積請求問題，好比：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，長此以往，全部請求都卡在調到第二臺上。
• 加權輪詢(Weighted Round Robbin)爲輪詢中的每臺服務器附加必定權重的算法。好比服務器1權重1，服務器2權重2，服務器3權重3，則順序爲1-2-2-3-3-3-1-2-2-3-3-3- ......

3. 最小鏈接及加權最小鏈接

• 最少鏈接(Least Connections)在多個服務器中，與處理鏈接數(會話數)最少的服務器進行通訊的算法。即便在每臺服務器處理能力各不相同，每筆業務處理量也不相同的狀況下，也可以在必定程度上下降服務器的負載。
• 加權最少鏈接(Weighted Least Connection)爲最少鏈接算法中的每臺服務器附加權重的算法，該算法事先爲每臺服務器分配處理鏈接的數量，並將客戶端請求轉至鏈接數最少的服務器上。

4. 哈希算法

• 普通哈希
• 一致性哈希一致性Hash，相同參數的請求老是發到同一提供者。當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。

5. IP地址散列

• 經過管理髮送方IP和目的地IP地址的散列，未來自同一發送方的分組(或發送至同一目的地的分組)統一轉發到相同服務器的算法。當客戶端有一系列業務須要處理而必須和一個服務器反覆通訊時，該算法可以以流(會話)爲單位，保證來自相同客戶端的通訊可以一直在同一服務器中進行處理。

6.URL散列

• 經過管理客戶端請求URL信息的散列，將發送至相同URL的請求轉發至同一服務器的算法。

4、負載均衡的實現（DNS > 數據鏈路層 > IP層 > Http層）？

1 - DNS域名解析負載均衡（延遲）

　利用DNS處理域名解析請求的同時進行負載均衡是另外一種經常使用的方案。在DNS服務器中配置多個A記錄，如：www.mysite.com IN A 114.100.80.一、www.mysite.com IN A 114.100.80.二、www.mysite.com IN A 114.100.80.3.
　每次域名解析請求都會根據負載均衡算法計算一個不一樣的IP地址返回，這樣A記錄中配置的多個服務器就構成一個集羣，並能夠實現負載均衡。
　DNS域名解析負載均衡的優勢是將負載均衡工做交給DNS，省略掉了網絡管理的麻煩，缺點就是DNS可能緩存A記錄，不受網站控制。事實上，大型網站老是部分使用DNS域名解析，做爲第一級負載均衡手段，而後再在內部作第二級負載均衡。

2 - 數據鏈路層負載均衡(LVS)

　數據鏈路層負載均衡是指在通訊協議的數據鏈路層修改mac地址進行負載均衡。
　這種數據傳輸方式又稱做三角傳輸模式，負載均衡數據分發過程當中不修改IP地址，只修改目的的mac地址，經過配置真實物理服務器集羣全部機器虛擬IP和負載均衡服務器IP地址同樣，從而達到負載均衡，這種負載均衡方式又稱爲直接路由方式（DR）.
　在上圖中，用戶請求到達負載均衡服務器後，負載均衡服務器將請求數據的目的mac地址修改成真是WEB服務器的mac地址，並不修改數據包目標IP地址，所以數據能夠正常到達目標WEB服務器，該服務器在處理完數據後能夠通過網管服務器而不是負載均衡服務器直接到達用戶瀏覽器。
　使用三角傳輸模式的鏈路層負載均衡是目前大型網站所使用的最廣的一種負載均衡手段。在linux平臺上最好的鏈路層負載均衡開源產品是LVS(linux virtual server)。

3 - IP負載均衡(SNAT)

　IP負載均衡：即在網絡層經過修改請求目標地址進行負載均衡。
　用戶請求數據包到達負載均衡服務器後，負載均衡服務器在操做系統內核進行獲取網絡數據包，根據負載均衡算法計算獲得一臺真實的WEB服務器地址，而後將數據包的IP地址修改成真實的WEB服務器地址，不須要經過用戶進程處理。真實的WEB服務器處理完畢後，相應數據包回到負載均衡服務器，負載均衡服務器再將數據包源地址修改成自身的IP地址發送給用戶瀏覽器。
　這裏的關鍵在於真實WEB服務器相應數據包如何返回給負載均衡服務器，一種是負載均衡服務器在修改目的IP地址的同時修改源地址，將數據包源地址改成自身的IP，即源地址轉換（SNAT），另外一種方案是將負載均衡服務器同時做爲真實物理服務器的網關服務器，這樣全部的數據都會到達負載均衡服務器。
　IP負載均衡在內核進程完成數據分發，較反向代理均衡有更好的處理性能。但因爲全部請求響應的數據包都須要通過負載均衡服務器，所以負載均衡的網卡帶寬成爲系統的瓶頸。

4 - HTTP重定向負載均衡(少見)

　HTTP重定向服務器是一臺普通的應用服務器，其惟一的功能就是根據用戶的HTTP請求計算一臺真實的服務器地址，並將真實的服務器地址寫入HTTP重定向響應中（響應狀態嗎302）返回給瀏覽器，而後瀏覽器再自動請求真實的服務器。
　這種負載均衡方案的優勢是比較簡單，缺點是瀏覽器須要每次請求兩次服務器才能拿完成一次訪問，性能較差；使用HTTP302響應碼重定向，多是搜索引擎判斷爲SEO做弊，下降搜索排名。重定向服務器自身的處理能力有可能成爲瓶頸。所以這種方案在實際使用中並不見多。

5 - 反向代理負載均衡(nginx)

　傳統代理服務器位於瀏覽器一端，代理瀏覽器將HTTP請求發送到互聯網上。而反向代理服務器則位於網站機房一側，代理網站web服務器接收http請求。
　反向代理的做用是保護網站安全，全部互聯網的請求都必須通過代理服務器，至關於在web服務器和可能的網絡攻擊之間創建了一個屏障。
　除此以外，代理服務器也能夠配置緩存加速web請求。當用戶第一次訪問靜態內容的時候，靜態內存就被緩存在反向代理服務器上，這樣當其餘用戶訪問該靜態內容時，就能夠直接從反向代理服務器返回，加速web請求響應速度，減輕web服務器負載壓力。
　另外，反向代理服務器也能夠實現負載均衡的功能。
　因爲反向代理服務器轉發請求在HTTP協議層面，所以也叫應用層負載均衡。優勢是部署簡單，缺點是可能成爲系統的瓶頸。