簡介幾種負載均衡原理

開頭先理解一下所謂的「均衡」

不能狹義地理解爲分配給全部實際服務器同樣多的工做量，由於多臺服務器的承載能力各不相同，這可能體如今硬件配置、網絡帶寬的差別，也可能由於某臺服務器身兼多職，咱們所說的「均衡」，也就是但願全部服務器都不要過載，而且可以最大程序地發揮做用。

1、http重定向

當http代理（好比瀏覽器）向web服務器請求某個URL後，web服務器能夠經過http響應頭信息中的Location標記來返回一個新的URL。這意味着HTTP代理須要繼續請求這個新的URL，完成自動跳轉。

 

性能缺陷：

一、吞吐率限制

主站點服務器的吞吐率平均分配到了被轉移的服務器。現假設使用RR（Round Robin）調度策略，子服務器的最大吞吐率爲1000reqs/s，那麼主服務器的吞吐率要達到3000reqs/s才能徹底發揮三臺子服務器的做用，那麼若是有100臺子服務器，那麼主服務器的吞吐率可想而知得有大？相反，若是主服務的最大吞吐率爲6000reqs/s，那麼平均分配到子服務器的吞吐率爲2000reqs/s，而現子服務器的最大吞吐率爲1000reqs/s，所以就得增長子服務器的數量，增長到6個才能知足。

二、重定向訪問深度不一樣

有的重定向一個靜態頁面，有的重定向相比複雜的動態頁面，那麼實際服務器的負載差別是不可預料的，而主站服務器卻一無所知。所以整站使用重定向方法作負載均衡不太好。

咱們須要權衡轉移請求的開銷和處理實際請求的開銷，前者相對於後者越小，那麼重定向的意義就越大，例以下載。你能夠去不少鏡像下載網站試下，會發現基本下載都使用了Location作了重定向。

2、DNS負載均衡

DNS負責提供域名解析服務，當訪問某個站點時，實際上首先須要經過該站點域名的DNS服務器來獲取域名指向的IP地址，在這一過程當中，DNS服務器完成了域名到IP地址的映射，一樣，這樣映射也能夠是一對多的，這時候，DNS服務器便充當了負載均衡調度器，它就像http重定向轉換策略同樣，將用戶的請求分散到多臺服務器上，可是它的實現機制徹底不一樣。

相比http重定向，基於DNS的負載均衡徹底節省了所謂的主站點，或者說DNS服務器已經充當了主站點的職能。但不一樣的是，做爲調度器，DNS服務器自己的性能幾乎不用擔憂。由於DNS記錄能夠被用戶瀏覽器或者互聯網接入服務商的各級DNS服務器緩存，只有當緩存過時後纔會從新向域名的DNS服務器請求解析。也說是DNS不存在http的吞吐率限制，理論上能夠無限增長實際服務器的數量。

特性:

一、能夠根據用戶IP來進行智能解析。DNS服務器能夠在全部可用的A記錄中尋找離用記最近的一臺服務器。

二、動態DNS：在每次IP地址變動時，及時更新DNS服務器。固然，由於緩存，必定的延遲不可避免。

不足：

一、沒有用戶能直接看到DNS解析到了哪一臺實際服務器，加服務器運維人員的調試帶來了不便。

二、策略的侷限性。例如你沒法將HTTP請求的上下文引入到調度策略中，而在前面介紹的基於HTTP重定向的負載均衡系統中，調度器工做在HTTP層面，它能夠充分理解HTTP請求後根據站點的應用邏輯來設計調度策略，好比根據請求不一樣的URL來進行合理的過濾和轉移。

三、若是要根據實際服務器的實時負載差別來調整調度策略，這須要DNS服務器在每次解析操做時分析各服務器的健康狀態，對於DNS服務器來講，這種自定義開發存在較高的門檻，更況且大多數站點只是使用第三方DNS服務。

四、DNS記錄緩存，各級節點的DNS服務器不一樣程序的緩存會讓你暈頭轉向。

五、基於以上幾點，DNS服務器並不能很好地完成工做量均衡分配，最後，是否選擇基於DNS的負載均衡方式徹底取決於你的須要。

 

3、反向代理負載均衡

這個確定你們都有所接觸，由於幾乎全部主流的Web服務器都熱衷於支持基於反向代理的負載均衡。它的核心工做就是轉發HTTP請求。

 

相比前面的HTTP重定向和DNS解析，反向代理的調度器扮演的是用戶和實際服務器中間人的角色：

一、任何對於實際服務器的HTTP請求都必須通過調度器

二、調度器必須等待實際服務器的HTTP響應，並將它反饋給用戶（前兩種方式不須要通過調度反饋，是實際服務器直接發送給用戶）

 

特性：

一、調度策略豐富。例如能夠爲不一樣的實際服務器設置不一樣的權重，以達到能者多勞的效果。

二、對反向代理服務器的併發處理能力要求高，由於它工做在HTTP層面。

三、反向代理服務器進行轉發操做自己是須要必定開銷的，好比建立線程、與後端服務器創建TCP鏈接、接收後端服務器返回的處理結果、分析HTTP頭部信息、用戶空間和內核空間的頻繁切換等，雖然這部分時間並不長，可是當後端服務器處理請求的時間很是短時，轉發的開銷就顯得尤其突出。例如請求靜態文件，更適合使用前面介紹的基於DNS的負載均衡方式。

四、反向代理服務器能夠監控後端服務器，好比系統負載、響應時間、是否可用、TCP鏈接數、流量等，從而根據這些數據調整負載均衡的策略。

五、反射代理服務器可讓用戶在一次會話週期內的全部請求始終轉發到一臺特定的後端服務器（粘滯會話），這樣的好處一是保持session的本地訪問，二是防止後端服務器的動態內存緩存的資源浪費。

 

4、IP負載均衡(LVS-NAT)

 

由於反向代理服務器工做在HTTP層，其自己的開銷就已經嚴重製約了可擴展性，從而也限制了它的性能極限。那可否在HTTP層面如下實現負載均衡呢？

NAT服務器:它工做在傳輸層，它能夠修改發送來的IP數據包，將數據包的目標地址修改成實際服務器地址。

從Linux2.4內核開始，其內置的Neftilter模塊在內核中維護着一些數據包過濾表，這些表包含了用於控制數據包過濾的規則。可喜的是，Linux提供了iptables來對過濾表進行插入、修改和刪除等操做。更加使人振奮的是，Linux2.6.x內核中內置了IPVS模塊，它的工做性質類型於Netfilter模塊，不過它更專一於實現IP負載均衡。

IPVS的管理工具是ipvsadm，它爲提供了基於命令行的配置界面，能夠經過它快速實現負載均衡系統。這就是大名鼎鼎的LVS(Linux Virtual Server，Linux虛擬服務器)。

一、打開調度器的數據包轉發選項

echo 1 > /proc/sys/net/ipv4/ip_forward

二、檢查實際服務器是否已經將NAT服務器做爲本身的默認網關，若是不是，如添加

route add default gw xx.xx.xx.xx

三、使用ipvsadm配置

ipvsadm -A -t 111.11.11.11:80 -s rr

添加一臺虛擬服務器，-t 後面是服務器的外網ip和端口，-s rr是指採用簡單輪詢的RR調度策略（這屬於靜態調度策略，除此以外，LVS還提供了系列的動態調度策略，好比最小鏈接（LC）、帶權重的最小鏈接（WLC），最短時間望時間延遲（SED）等）

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -m

ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.211:8000 -m

添加兩臺實際服務器（不須要有外網ip），-r後面是實際服務器的內網ip和端口，-m表示採用NAT方式來轉發數據包

運行ipvsadm -L -n能夠查看實際服務器的狀態。這樣就大功告成了。

實驗證實使用基於NAT的負載均衡系統。做爲調度器的NAT服務器能夠將吞吐率提高到一個新的高度，幾乎是反向代理服務器的兩倍以上，這大多歸功於在內核中進行請求轉發的較低開銷。可是一旦請求的內容過大時，不管是基於反向代理仍是NAT，負載均衡的總體吞吐量都差距不大，這說明對於一睦開銷較大的內容，使用簡單的反向代理來搭建負載均衡系統是值考慮的。

這麼強大的系統仍是有它的瓶頸，那就是NAT服務器的網絡帶寬，包括內部網絡和外部網絡。固然若是你不差錢，能夠去花錢去購買千兆交換機或萬兆交換機，甚至負載均衡硬件設備，但若是你是個屌絲，咋辦？

 

一個簡單有效的辦法就是將基於NAT的集羣和前面的DNS混合使用，好比５個100Mbps出口寬帶的集羣，而後經過DNS來將用戶請求均衡地指向這些集羣，同時，你還能夠利用DNS智能解析實現地域就近訪問。這樣的配置對於大多數業務是足夠了，可是對於提供下載或視頻等服務的大規模站點，NAT服務器仍是不夠出色。

5、直接路由(LVS-DR)

NAT是工做在網絡分層模型的傳輸層（第四層），而直接路由是工做在數據鏈路層（第二層），貌似更屌些。它經過修改數據包的目標MAC地址（沒有修改目標IP），將數據包轉發到實際服務器上，不一樣的是，實際服務器的響應數據包將直接發送給客戶羰，而不通過調度器。

一、網絡設置

這裏假設一臺負載均衡調度器，兩臺實際服務器，購買三個外網ip，一臺機一個，三臺機的默認網關須要相同，最後再設置一樣的ip別名，這裏假設別名爲10.10.120.193。這樣一來，將經過10.10.120.193這個IP別名來訪問調度器，你能夠將站點的域名指向這個IP別名。

二、將ip別名添加到迴環接口lo上

這是爲了讓實際服務器不要去尋找其餘擁有這個IP別名的服務器，在實際服務器中運行：

另外還要防止實際服務器響應來自網絡中針對IP別名的ARP廣播，爲此還要執行：

echo "1" > /proc/sys/net/ipv4/conf/lo/arp_ignore

echo "2" > /proc/sys/net/ipv4/conf/lo/arp_announce

echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignore

echo "1" > /proc/sys/net/ipv4/conf/all/arp_announce

配置完了就可使用ipvsadm配置LVS-DR集羣了

ipvsadm -A -t 10.10.120.193:80 -s rr

ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:8000 -g

ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.211:8000 -g

-g 就意味着使用直接路由的方式轉發數據包

LVS-DR 相較於LVS-NAT的最大優點在於LVS-DR不受調度器寬帶的限制，例如假設三臺服務器在WAN交換機出口寬帶都限制爲10Mbps，只要對於鏈接調度器和兩臺實際服務器的LAN交換機沒有限速，那麼，使用LVS-DR理論上能夠達到20Mbps的最大出口寬帶，由於它的實際服務器的響應數據包能夠不通過調度器而直接發往用戶端啊，因此它與調度器的出口寬帶沒有關係，只能自身的有關係。而若是使用LVS-NAT，集羣只能最大使用10Mbps的寬帶。因此，越是響應數據包遠遠超過請求數據包的服務，就越應該下降調度器轉移請求的開銷，也就越能提升總體的擴展能力，最終也就越依賴於WAN出口寬帶。

總的來講，LVS-DR適合搭建可擴展的負載均衡系統，不管是Web服務器仍是文件服務器，以及視頻服務器，它都擁有出色的性能。前提是你必須爲實際器購買一系列的合法IP地址。

6、IP隧道(LVS-TUN)

基於IP隧道的請求轉發機制：將調度器收到的IP數據包封裝在一個新的IP數據包中，轉交給實際服務器，而後實際服務器的響應數據包能夠直接到達用戶端。目前Linux大多支持，能夠用LVS來實現，稱爲LVS-TUN，與LVS-DR不一樣的是，實際服務器能夠和調度器不在同一個WANt網段，調度器經過IP隧道技術來轉發請求到實際服務器，因此實際服務器也必須擁有合法的IP地址。

整體來講，LVS-DR和LVS-TUN都適合響應和請求不對稱的Web服務器，如何從它們中作出選擇，取決於你的網絡部署須要，由於LVS-TUN能夠將實際服務器根據須要部署在不一樣的地域，而且根據就近訪問的原則來轉移請求，因此有相似這種需求的，就應該選擇LVS-TUN。

 

本文屬於原創，若有疑問請後臺留言，若有轉載請標註原做者，版權歸本公衆號全部。若是你喜歡我寫的文章請關注微信公衆號 全棧開發者社區，歡迎你們繼續關注本公衆號的技術博文。若是您以爲本文章對你有所幫助的話，不妨點個贊，您的支持就是我堅持原創的動力。