概述
文章負載均衡（Load Balancing）學習筆記(一) 講述了負載均衡的一般性原理，本文繼續介紹常見的實現負載均衡的方法。
HTTP重定向
HTTP重定向服務器是一臺普通的Web服務器，用戶的請求先到達重定向服務器，這臺服務器會挑選一臺後端服務器的地址（例如使用輪詢的方式），並將該地址寫入HTTP重定向響應結果中（以響應狀態碼302返回）返回給用戶。用戶將根據這個新的地址重新發送請求到選中的服務器上。選中的服務器會處理用戶請求，並將結果返回給用戶。
HTTP重定向的處理流程如圖1所示。
圖1：HTTP重定向實現負載均衡
通過重定向服務器的處理，用戶請求被分配到不同的後端服務器上進行處理，實現了負載均衡的目的。
優點
HTTP重定向負載均衡的方法實現上比較簡單。
缺點
- 增加了用戶的時延，因爲訪問請求需要進行兩次往返
- 重定向服務器沒有將後端服務器的負載差異考慮進去，有些後端服務器可能在相當繁忙時仍然接收到較多的請求
- 重定向服務器的併發處理能力制約着整個系統的併發處理能力
- 如果重定向服務器出現故障，站點就會癱瘓
由於存在這些缺點，HTTP重定向通常都會與其他一種或多種負載均衡技術結合使用。
DNS負載均衡
DNS負載均衡的實現原理是在DNS服務器中爲同一個主機名配置多個IP地址，在應答DNS查詢時，DNS服務器對於每個查詢將以DNS記錄的IP地址按順序返回不同的解析結果，將客戶端的訪問引導到不同的機器上去，使得不同客戶端訪問不同的服務器，從而達到負載均衡的目的。
圖2：DNS實現負載均衡
優點
- 由於DNS系統本身是一個分佈式系統，相對來說它不存在性能和吞吐能力的限制，故使用DNS來做負載均衡並不需要擔心負載均衡服務器的處理能力
- 可以根據用戶IP進行智能解析，DNS服務器可以在所有可用的A記錄中尋找離用戶最近的一臺服務器爲用戶提供服務
##缺點
- DNS服務器並不知道後端服務器的情況，如果後端服務器宕機，而用戶的請求繼續被分配到這個後端服務器，會導致無法響應用戶的請求
- DNS服務器依然沒有將後端服務器的負載差異考慮進去
- DNS服務器存在緩存，當需要更新請求的分配時，新增一個IP或者刪除一個IP並不能立即生效
反向代理
反向代理服務器的工作主要是轉發HTTP請求，因此它工作在HTTP層，也就是OSI七層結構中的應用層（第七層），所以基於反向代理的負載均衡也稱爲七層負載均衡。利用反向代理服務器進行負載均衡，如圖3所示。
圖3：反向代理實現負載均衡
反向代理服務處於後端服務器的前面，由於需要直接受用戶的請求，故反向代理服務器需要一個外網IP。而後端服務器並不直接對外提供訪問，因此後端服務器並不需要外網IP。反向代理服務器通過內網IP與後端服務器進行通信。圖3中，瀏覽器的請求到達反向代理服務器114.113.200.84，反向代理服務器收到請求後，根據負載均衡算法計算得到一臺真實的後端服務器地址10.0.0.1，並將請求轉發到這臺後端服務器。10.0.0.1處理請求後將響應返回給反向代理服務器，再由反向代理服務器將該響應返回給用戶。
常見的反向代理服務器包括Nginx，Apache，Haproxy等。
優點
- 部署比較簡單，使用常見的反向代理服務器軟件即可部署反向代理服務器
- 調度策略豐富，例如，可以爲不同的後端機器設置不同的分配權重， 這樣處理能力高的機器可以分配到較多的任務，達到能者多勞的目的
- 反向代理服務器可以讓用戶在一次會話週期內的所有請求始終分配到一臺特定的後端服務器（粘滯會話）
缺點
由於反向代理工作在HTTP層，所有請求都需要經過反向代理服務器的處理，後端服務器的響應結果也必須經過反向代理服務器傳送給用戶，故這種負載均衡方式要求反向代理的併發處理能力較高。
IP負載均衡
我們已瞭解前面幾種負載均衡的方法，這些負載均衡都是工作在HTTP層，那麼，能否在HTTP層以下來實現負載均衡呢？答案是肯定的。事實上，在數據鏈路層（第二層），網絡層（第三層），以及傳輸層（第四層）都可以實現不同機制的負載均衡。但與HTTP層機制不同，這些負載均衡調度的工作必須由Linux內核來完成，即網絡數據包在從內核緩衝區進入用戶進程空間前，已完成轉發的工作。
在網絡層通過修改請求目的地址進行負載均衡的流程如圖4所示。
圖4：IP負載均衡
用戶請求到達負載均衡服務器114.113.200.84，負載均衡服務器在操作系統內核獲取網絡數據包，根據負載均衡算法計算得到一臺真實的後端服務器10.0.0.1，然後將數據包的目地址改爲10.0.0.1，不需要用戶進程處理。後端服務器10.0.0.1處理完成後，響應數據包返回到負載均衡服務器，負載均衡服務器再將數據包源地址修改爲自身的IP地址（114.113.200.84）發送給用戶。
優點
IP負載均衡在內核進程完成數據分發，處理性能得到了很大的提高。
缺點
由於所有請求和響應都要經過負載均衡服務器，系統的最大吞吐量仍然受到負載均衡服務器網卡帶寬的限制。對於提供下載服務或者視頻服務等需要傳輸大量數據站點，IP負載均衡的方式是難以滿足需求的。
數據鏈路層負載均衡
數據鏈路層負載均衡通過修改數據幀的MAC地址來實現負載均衡的目的。數據鏈路層是OSI網絡模型的第二層，由於數據鏈路層負載均衡的方法走的是MAC層的協議，因此需要負載均衡服務器和後端服務器處在同一個二層（同一個廣播域）之中。
數據鏈路層負載均衡的工作流程如圖所示：
圖5：數據鏈路層實現負載均衡
圖5所示的數據傳輸方式又稱作三角傳輸模式，負載均衡數據分發過程中不修改IP址，只修改MAC地址，通過配置後端服務器與負載均衡服務器具有相同的IP地址，從而達到不修改數據包的源IP地址和目的IP地址就可以進行數據分發的目的。由於後端服務器的IP和數據請求目的IP一致，不需要通過負載均衡服務器進行地址轉換，可以將響應數據包直接返回給用戶瀏覽器，避免負載均衡服務器網卡帶寬成爲瓶頸。
圖5中，用戶請求到達負載均衡服務器114.113.200.84，負載均衡服務器將請求數據的目的MAC地址必爲00.0c.29.d2，並不修改數據包目的IP地址，由於後端服務器與負載均衡服務器並有相同的IP地址，因此數據可以正常傳輸到達00.0c.29.d2對應的服務器，該服務器處理完成後將響應數據直接返回給用戶，不需要經過負載均衡服務器。
在Linux平臺上最好的數據鏈路層負載均衡的開源產品是LVS（Linux Virtual Server）。LVS有三種運行模式，分別爲NAT模式，TUN模式，DR模式。DR模式正是運行在數據鏈路層，通過修改數據幀的MAC地址來實現負載均衡的。
優點
- 數據鏈路層負載均衡工作在Linux內核進程，性能很高
- 後端服務器的響應不需要再次經過負載均衡服務器，解決了負載均衡服務器網卡流量瓶頸的問題
缺點
可配置性較高，並不支持複雜的調度策略。
參考資料
- 大型網站技術架構——核心原理與安全分析，李智慧著，電子工業出版社
- 構建高性能Web站點，郭欣著，中國工信出版集團，電子工業出版社
- HTTP權威指南，David Gourley等著，人民郵電出版社
- https://segmentfault.com/a/1190000002578457
- http://baike.baidu.com/item/DNS負載均衡
- http://blog.csdn.net/asqi1/article/details/41478111
注：轉載自https://leehao.me