負載均衡（load balance）是分佈式系統架構設計中必須考慮的因素之一。它通常指的是將請求/數據“均衡”的分攤給多個操作單元來執行，負載均衡的關鍵在於“均衡”。均衡不能狹義的理解爲平均把工作分配給每一臺服務器，每個服務器的承載能力各不相同，可能是因爲硬件配置，網絡寬帶的差異，也有可能是因爲某臺服務器身兼數職。我們所說的負載均衡，主要希望可以讓所有服務器都不要過載，並且最大程度的發揮作用。下面講述一下負載均衡的目前技術。
一、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會先通過該站點域名的DNS服務器獲得該域名指向的IP地址。在這一過程中,DNS完成了域名到IP的映射，同樣這樣的映射也可以是一對多的，這個時候DNS就充當了一個負載均衡的調度器，他就像http重定向策略一樣，將訪問請求分發到多臺服務器上，但是他的實現機制完全不同。
使用dig命令查看百度的DNS設置
baidu.com擁有四個A記錄
相比於http重定向，基於DNS負載均衡完全節省了主站點，DNS已經充當了主站點的職能。但不同的是，同樣作爲調度器的DNS服務器是幾乎不用擔心性能的，因爲DNS記錄是會被用戶的瀏覽器和互聯網接入的服務商的各級DNS服務器緩存，只有緩存過期纔會想DNS服務器重新請求解析，DNS服務器不存在http吞吐率的限制，理論上可以無限增加服務器的數量。
特點：
1.可以根據用戶的IP來進行智能解析。DNS可以在所有可用的A記錄中找到一臺距離用戶最近的服務器。
2.動態DNS:每次在IP地址變更時，及時更新DNS服務器。因爲緩存，一定的延遲（立即生效大概15分鐘）。
缺點：
1.沒有用戶能直接看到DNS解析到了哪一臺服務器，給服務器的運維人員調試帶來了不便。
2.策略的侷限性。例如無法將http的上下文引入到調度策略中，前文介紹的http重定向負載均衡系統中，調度工作在http層面，它可以充分的理解http的請求根據站點的應用邏輯來設計調度策略，比如根據不同的url來進行合理的過濾和轉移。
3.如果要根據實際服務器的負載差異來調整調度策略，那麼需要DNS服務器在每次解析操作的時候分析各服務器的健康狀態，這對DNS服務器來說，這種自定義開發存在較高的門檻，而且大部分的站點使用的是第三方的DNS服務器。
4.DNS記錄緩存，各節點的DNS服務器不同程序的緩存會讓你暈頭轉向。
總結：
DNS服務器並不能很好的完成負載均衡的分配工作，是否選擇取決於你的需要。
三、反向代理負載均衡
幾乎所有的web服務器都熱衷於支持基於方向代理的負載均衡，它的核心工作就是轉發http請求。相比於http重定向和DNS解析，反向代理扮演的就是中間人的角色，任何對於實際服務器的http請求都必須經過調度器，調度器必須等待實際服務器的HTTP響應，並將它反饋給用戶。
特性：
1.調度策略豐富，可以爲不同的服務器設置不同的權重，達到能者多勞的效果。
2.對反向代理服務器的併發處理能力要求高，因爲他工作在HTTP層面。
3.反向代理服務器進行轉發操作本身是需要一定開銷的，比如創建線程，與後端服務器建立TCP連接，接收後端服務器的返回結果，分析http的頭部信息、用戶空間和內核空間的頻繁切換等，雖然這部分時間並不長，但是當後端服務器處理請求的耗時特別短，轉發的開銷就顯得尤爲突出。例如請求靜態文件更適合前面介紹的DNS負載均衡方式。
4.反向代理服務器可以監控後端服務器，比如系統負載，響應時間，是否可用，TCP鏈接數、流量等從而可以根據這些數據調整負載均衡的策略。
5.反向代理服務器可以讓用戶在一次會話週期內所有的請求始終轉發在一臺特定的後端服務器上（黏滯會話），這樣的好處一是保持session本地訪問，二是防止後端服務器的動態內容緩存的資源浪費。
四、LVS負載均衡
LVS是Linux Virtual Server的簡稱，也就是Linux虛擬服務器,現在LVS是linux標準內核的一部分。
1.LVS-NAT（IP負載均衡）
因爲反向代理工作在HTTP層，其本身的開銷就已經嚴重的制約了可擴展性，從而限制了他的性能極限。NAT服務器工作在傳輸層，他可以修改發來的IP數據包，將數據包的目標地址修改爲實際服務器地址。
從linux2.4內核開始，其內置的Neftilter模塊在內核中維護着一些數據包過濾表，這些表包含了數據包過濾的規則。Linux提供了iptables來對過濾表進行插入、修改和刪除等操作。Linux2.6內核中內置了IPVS模塊，他的工作性質類似於Neftilter，不過他更專注於實現IP負載均衡。
IPVS的管理工具是ipvsadm，它提供了基於命令行的配置界面，可以通過他快速實現負載均衡系統。
①打開調度器的數據包轉發選項
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方式來轉發數據包。
運行ipvs - L -n可以查看實際服務器的狀態。
實驗證明使用基於NAT的負載均衡系統可以將吞吐率提升到一個新的高度，幾乎是反向代理的兩倍，這歸功於內核請求轉發較低的開銷。但是一旦請求內容太大，不論是反向代理還是NAT，負載均衡整體的吞吐率差距不大，這說明對於開銷較大的內容，使用反向代理是值得考慮的。NAT負載均衡系統的瓶頸在於NAT服務器的網絡帶寬，包括內部網絡和外部網絡。如果不差錢可以花錢購買千兆交換機或者萬兆交換機，甚至負載均衡設備。如果沒錢可以使用基於NAT的集羣和DNS混用，比如５個100Mbps出口寬帶的集羣，然後通過DNS來將用戶請求均衡地指向這些集羣，同時，你還可以利用DNS智能解析實現地域就近訪問。這樣的配置對於大多數業務是足夠了，但是對於提供下載或視頻等服務的大規模站點，NAT服務器還是不夠出色。
優點:
- 對後端服務器的操作系統無要求
- 只需要一個IP地址配置在調度器上，服務器組可以使用私有的IP
- 支持端口映射缺點
缺點：
- 請求和響應報文都需要經過調度器，伸縮能力有限
- 要求服務器和調度器在同一個VLAN
- 需要將服務器的默認網關指向調度器
- 對於那些將IP地址或者端口號在報文數據中傳送的網絡服務，需要編寫相應的應用模塊來轉換報文數據中的IP和端口號
2.LVS-DR（直接路由）
NAT是工作在網絡分層的傳輸層（4層），而直接路由是工作在數據鏈路層（第二層），他通過修改數據包的MAC地址，將數據包轉發到實際服務器，不同的是，實際服務器的響應數據包是直接發送給客戶端的，不經過調度器。
①網絡設置
這裏假設一臺負載均衡調度器，兩臺實際服務器，購買三個外網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地址。
優點：
- 與LVS-TUN相比，沒有IP隧道的開銷，性能最好
缺點：
- 要求調度器和服務器都有一塊網卡連在同一物理網段（同一個VLAN）上
- 要求服務器網絡設備不做ARP廣播響應，或者能將報文重定向到本地的SOCKET端口上
- 服務器上直接綁定虛擬IP（Virtaul IP），風險很大
- 不支持端口映射
3.LVS-TUN（IP隧道）
基於IP隧道的請求轉發機制：將調度器收到的IP數據包封裝在一個新的IP數據包中，轉交給實際服務器，然後實際服務器的響應數據包可以直接到達用戶端。目前Linux大多支持，可以用LVS來實現，稱爲LVS-TUN，與LVS-DR不同的是，實際服務器可以和調度器不在同一個WANt網段，調度器通過IP隧道技術來轉發請求到實際服務器，所以實際服務器也必須擁有合法的IP地址。
總體來說，LVS-DR和LVS-TUN都適合響應和請求不對稱的Web服務器，如何從它們中做出選擇，取決於你的網絡部署需要，因爲LVS-TUN可以將實際服務器根據需要部署在不同的地域，並且根據就近訪問的原則來轉移請求，所以有類似這種需求的，就應該選擇LVS-TUN。
優點：
- 不需要調度應答報文，性能高
- 服務器和調度器可以不再一個VLAN
- 支持廣域負載均衡
缺點：
- 所有服務器必須支持“IP Tunneling”協議，要安裝內核模塊（比如IPIP等），配置複雜
- 有建立IP隧道的開銷
- 服務器上直接綁定虛擬IP，風險很大
- 服務器需要聯通外網
- 不支持端口映射
註釋：
1.網絡七層協議：從上到下分別是應用層、表示層、會話層、傳輸層、網絡層、數據鏈路層、物理層。
2.TCP/IP四層協議:從上到下分別是網絡接口層、互連網絡層、傳輸層、應用層。