不能狹義地理解為分配給所有實際伺服器一樣多的工作量，因為多臺伺服器的承載能力各不相同，這可能體現在硬體配置、網路頻寬的差異，也可能因為某臺伺服器身兼多職，我們所說的“均衡”，也就是希望所有伺服器都不要過載，並且能夠最大程式地發揮作用。

 

一、http重定向

當http代理（比如瀏覽器）向web伺服器請求某個URL後，web伺服器可以通過http響應頭資訊中的Location標記來返回一個新的URL。這意味著HTTP代理需要繼續請求這個新的URL，完成自動跳轉。

 

效能缺陷：

1、吞吐率限制

主站點伺服器的吞吐率平均分配到了被轉移的伺服器。現假設使用RR（Round Robin）排程策略，子伺服器的最大吞吐率為1000reqs/s，那麼主伺服器的吞吐率要達到3000reqs/s才能完全發揮三臺子伺服器的作用，那麼如果有100臺子伺服器，那麼主伺服器的吞吐率可想而知得有大？相反，如果主服務的最大吞吐率為6000reqs/s，那麼平均分配到子伺服器的吞吐率為2000reqs/s，而現子伺服器的最大吞吐率為1000reqs/s，因此就得增加子伺服器的數量，增加到6個才能滿足。

 

2、重定向訪問深度不同

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

 

我們需要權衡轉移請求的開銷和處理實際請求的開銷，前者相對於後者越小，那麼重定向的意義就越大，例如下載。你可以去很多映象下載網站試下，會發現基本下載都使用了Location做了重定向。

 

二、DNS負載均衡

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

 

使用dig命令來看下"baidu"的DNS設定

可見baidu擁有三個A記錄

 

相比http重定向，基於DNS的負載均衡完全節省了所謂的主站點，或者說DNS伺服器已經充當了主站點的職能。但不同的是，作為排程器，DNS伺服器本身的效能幾乎不用擔心。因為DNS記錄可以被使用者瀏覽器或者網際網路接入服務商的各級DNS伺服器快取，只有當快取過期後才會重新向域名的DNS伺服器請求解析。也說是DNS不存在http的吞吐率限制，理論上可以無限增加實際伺服器的數量。

 

特性:

1、可以根據使用者IP來進行智慧解析。DNS伺服器可以在所有可用的A記錄中尋找離用記最近的一臺伺服器。

2、動態DNS：在每次IP地址變更時，及時更新DNS伺服器。當然，因為快取，一定的延遲不可避免。

 

不足：

1、沒有使用者能直接看到DNS解析到了哪一臺實際伺服器，加伺服器運維人員的除錯帶來了不便。

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

3、如果要根據實際伺服器的實時負載差異來調整排程策略，這需要DNS伺服器在每次解析操作時分析各伺服器的健康狀態，對於DNS伺服器來說，這種自定義開發存在較高的門檻，更何況大多數站點只是使用第三方DNS服務。

4、DNS記錄快取，各級節點的DNS伺服器不同程式的快取會讓你暈頭轉向。

5、基於以上幾點，DNS伺服器並不能很好地完成工作量均衡分配，最後，是否選擇基於DNS的負載均衡方式完全取決於你的需要。

 

三、反向代理負載均衡

這個肯定大家都有所接觸，因為幾乎所有主流的Web伺服器都熱衷於支援基於反向代理的負載均衡。它的核心工作就是轉發HTTP請求。

相比前面的HTTP重定向和DNS解析，反向代理的排程器扮演的是使用者和實際伺服器中間人的角色：

1、任何對於實際伺服器的HTTP請求都必須經過排程器

2、排程器必須等待實際伺服器的HTTP響應，並將它反饋給使用者（前兩種方式不需要經過排程反饋，是實際伺服器直接傳送給使用者）

 

特性：

1、排程策略豐富。例如可以為不同的實際伺服器設定不同的權重，以達到能者多勞的效果。

2、對反向代理伺服器的併發處理能力要求高，因為它工作在HTTP層面。

3、反向代理伺服器進行轉發操作本身是需要一定開銷的，比如建立執行緒、與後端伺服器建立TCP連線、接收後端伺服器返回的處理結果、分析HTTP頭部資訊、使用者空間和核心空間的頻繁切換等，雖然這部分時間並不長，但是當後端伺服器處理請求的時間非常短時，轉發的開銷就顯得尤為突出。例如請求靜態檔案，更適合使用前面介紹的基於DNS的負載均衡方式。

4、反向代理伺服器可以監控後端伺服器，比如系統負載、響應時間、是否可用、TCP連線數、流量等，從而根據這些資料調整負載均衡的策略。

5、反射代理伺服器可以讓使用者在一次會話週期內的所有請求始終轉發到一臺特定的後端伺服器上（粘滯會話），這樣的好處一是保持session的本地訪問，二是防止後端伺服器的動態記憶體快取的資源浪費。

 

 

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

因為反向代理伺服器工作在HTTP層，其本身的開銷就已經嚴重製約了可擴充套件性，從而也限制了它的效能極限。那能否在HTTP層面以下實現負載均衡呢？

 

NAT伺服器:它工作在傳輸層，它可以修改傳送來的IP資料包，將資料包的目標地址修改為實際伺服器地址。

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

想知道你的伺服器核心是否已經安裝了IPVS模組，可以

有輸出意味著IPVS已經安裝了。IPVS的管理工具是ipvsadm，它為提供了基於命令列的配置介面，可以通過它快速實現負載均衡系統。這就是大名鼎鼎的LVS(Linux Virtual Server，Linux虛擬伺服器)。

 

1、開啟排程器的資料包轉發選項

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

2、檢查實際伺服器是否已經將NAT伺服器作為自己的預設閘道器，如果不是，如新增

route add default gw xx.xx.xx.xx

3、使用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伺服器還是不夠出色。

 

五、直接路由(LVS-DR)

NAT是工作在網路分層模型的傳輸層（第四層），而直接路由是工作在資料鏈路層（第二層），貌似更屌些。它通過修改資料包的目標MAC地址（沒有修改目標IP），將資料包轉發到實際伺服器上，不同的是，實際伺服器的響應資料包將直接傳送給客戶羰，而不經過排程器。

1、網路設定

這裡假設一臺負載均衡排程器，兩臺實際伺服器，購買三個外網ip，一臺機一個，三臺機的預設閘道器需要相同，最後再設定同樣的ip別名，這裡假設別名為 10.10.120.193。這樣一來，將通過10.10.120.193這個IP別名來訪問排程器，你可以將站點的域名指向這個IP別名。

2、將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地址。

 

六、IP隧道(LVS-TUN)

基於IP隧道的請求轉發機制：將排程器收到的IP資料包封裝在一個新的IP資料包中，轉交給實際伺服器，然後實際伺服器的響應資料包可以直接到達使用者端。目前Linux大多支援，可以用LVS來實現，稱為LVS-TUN，與LVS-DR不同的是，實際伺服器可以和排程器不在同一個WANt網段，排程器通過 IP隧道技術來轉發請求到實際伺服器，所以實際伺服器也必須擁有合法的IP地址。

 

總體來說，LVS-DR和LVS-TUN都適合響應和請求不對稱的Web伺服器，如何從它們中做出選擇，取決於你的網路部署需要，因為LVS-TUN可以將實際伺服器根據需要部署在不同的地域，並且根據就近訪問的原則來轉移請求，所以有類似這種需求的，就應該選擇LVS-TUN。