還有個姊妹篇也可以參考這個文章：LVS(Linus Virtual Server)：三種IP負載均衡方式比較+另三種Web負載均衡方式
我還寫了一篇：【系統架構】億級Web系統搭建（1）：Web負載均衡(阿里)
LVS 實現了IP負載均衡，包含三個方法：NAT,DR,TUN
zookeeper使用ZAB(zookeeper Atomic Broadcast)協議保證數據一致性，
有興趣的參考：zookeeper 負載均衡 核心機制 包含ZAB協議(滴滴，阿里面試)
很多博客都說不明白，這里做一下總結：常用的6種負載均衡 3中IP負載均衡和 3中web負載均衡
開頭先理解一下所謂的“均衡”
不能狹義地理解為分配給所有實際服務器一樣多的工作量，因為多台服務器的承載能力各不相同，這可能體現在硬件配置、網絡帶寬的差異，也可能因為某台服務器身兼多職，我們所說的“均衡”，也就是希望所有服務器都不要過載，並且能夠最大程序地發揮作用。
然后看一下網絡圖：
不管是4層還是7層， 網絡層 和運輸層是相同的；這張圖也是阿里經常問的，具體我做了總結參考：七層協議和四層協議（阿里）
一、http重定向
[協議層] http重定向協議實現負載均衡
原理：根據用戶的http請求計算出一個真實的web服務器地址，並將該web服務器地址寫入http重定向響應中返回給瀏覽器，由瀏覽器重新進行訪問。
優點：比較簡單
缺點：
(1) 瀏覽器需要每次請求服務器才能完成一次訪問，性能較差。
http重定向服務器自身的處理能力可能成為瓶頸。
使用http302響應重定向，有可能使搜索引擎判斷為SEO作弊，降低搜索排名。
當http代理（比如瀏覽器）向web服務器請求某個URL后，web服務器可以通過http響應頭信息中的Location標記來返回一個新的URL。這意味着HTTP代理需要繼續請求這個新的URL，完成自動跳轉。
(2)、吞吐率限制
主站點服務器的吞吐率平均分配到了被轉移的服務器。現假設使用RR（Round Robin）調度策略，子服務器的最大吞吐率為1000reqs/s，那么主服務器的吞吐率要達到3000reqs/s才能完全發揮三台子服務器的作用，那么如果有100台子服務器，那么主服務器的吞吐率可想而知得有大？相反，如果主服務的最大吞吐率為6000reqs/s，那么平均分配到子服務器的吞吐率為2000reqs/s，而現子服務器的最大吞吐率為1000reqs/s，因此就得增加子服務器的數量，增加到6個才能滿足。
(3)、重定向訪問深度不同
有的重定向一個靜態頁面，有的重定向相比復雜的動態頁面，那么實際服務器的負載差異是不可預料的，而主站服務器卻一無所知。因此整站使用重定向方法做負載均衡不太好。
我們需要權衡轉移請求的開銷和處理實際請求的開銷，前者相對於后者越小，那么重定向的意義就越大，例如下載。你可以去很多鏡像下載網站試下，會發現基本下載都使用了Location做了重定向。
二、DNS負載均衡(采用的是簡單的輪詢算法)
[協議層】dns域名解析負載均衡
原理：在DNS服務器上配置多個域名對應IP的記錄。例如一個域名www.baidu.com對應一組web服務器IP地址，域名解析時經過DNS服務器的算法將一個域名請求分配到合適的真實服務器上。
優點：將負載均衡的工作交給了DNS，省卻了網站管理維護負載均衡服務器的麻煩，同事許多DNS還支持基於地理位置的域名解析，將域名解析成距離用戶地理最近的一個服務器地址，加快訪問速度嗎，改善性能。
缺點：目前的DNS解析是多級解析，每一級DNS都可能化緩存記錄A，當某一服務器下線后，該服務器對應的DNS記錄A可能仍然存在，導致分配到該服務器的用戶訪問失敗。
DNS負載均衡的控制權在域名服務商手里，網站可能無法做出過多的改善和管理。
不能夠按服務器的處理能力來分配負載。DNS負載均衡采用的是簡單的輪詢算法，不能區分服務器之間的差異，不能反映服務器當前運行狀態，所以其的負載均衡效果並不是太好。
可能會造成額外的網絡問題。為了使本DNS服務器和其他DNS服務器及時交互，保證DNS數據及時更新，使地址能隨機分配，一般都要將DNS的刷新時間設置的較小，但太小將會使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的負載均衡方式完全取決於你的需要。
三、反向代理負載均衡
【協議層】反向代理負載均衡 反向代理服務器工作在HTTP層
原理：反向代理處於web服務器這邊，反向代理服務器提供負載均衡的功能，同時管理一組web服務器，它根據負載均衡算法將請求的瀏覽器訪問轉發到不同的web服務器處理，處理結果經過反向服務器返回給瀏覽器。
例如：瀏覽器訪問請求的地址是反向代理服務器的地址114.100.80.10，反向代理服務器收到請求，經過負載均衡算法后得到一個真實物理地址10.0.03，並將請求結果發給真實的服務，真實服務器處理完后通過反向代理服務器返回給請求用戶。
優點：部署簡單，處於http協議層面。
缺點：使用了反向代理服務器后，web 服務器地址不能直接暴露在外，因此web服務器不需要使用外部IP地址，而反向代理服務作為溝通橋梁就需要配置雙網卡、外部內部兩套IP地址。
這個肯定大家都有所接觸，因為幾乎所有主流的Web服務器都熱衷於支持基於反向代理的負載均衡。它的核心工作就是轉發HTTP請求。
相比前面的HTTP重定向和DNS解析，反向代理的調度器扮演的是用戶和實際服務器中間人的角色：
1、任何對於實際服務器的HTTP請求都必須經過調度器
2、調度器必須等待實際服務器的HTTP響應，並將它反饋給用戶（前兩種方式不需要經過調度反饋，是實際服務器直接發送給用戶）
特性：
1、調度策略豐富。例如可以為不同的實際服務器設置不同的權重，以達到能者多勞的效果。
2、對反向代理服務器的並發處理能力要求高，因為它工作在HTTP層面。
3、反向代理服務器進行轉發操作本身是需要一定開銷的，比如創建線程、與后端服務器建立TCP連接、接收后端服務器返回的處理結果、分析HTTP頭部信息、用戶空間和內核空間的頻繁切換等，雖然這部分時間並不長，但是當后端服務器處理請求的時間非常短時，轉發的開銷就顯得尤為突出。例如請求靜態文件，更適合使用前面介紹的基於DNS的負載均衡方式。
4、反向代理服務器可以監控后端服務器，比如系統負載、響應時間、是否可用、TCP連接數、流量等，從而根據這些數據調整負載均衡的策略。
5、反射代理服務器可以讓用戶在一次會話周期內的所有請求始終轉發到一台特定的后端服務器上（粘滯會話），這樣的好處一是保持session的本地訪問，二是防止后端服務器的動態內存緩存的資源浪費。
四、IP負載均衡-NAT(LVS-NAT Linux Virtual Server-Network Address Translation)
【四層架構的傳輸層】IP負載均衡
原理：通過修改目標地址進行負載均衡。
用戶訪問請求到達負載均衡服務器，負載均衡服務器在操作系統內核進程獲取網絡數據包，根據算法得到一台真實服務器地址，然后將用戶請求的目標地址修改成該真實服務器地址，數據處理完后返回給負載均衡服務器，負載均衡服務器收到響應后將自身的地址修改成原用戶訪問地址后再講數據返回回去。類似於反向服務器負載均衡。
優點：在響應請求時速度較反向服務器負載均衡要快。
缺點：當請求數據較大（大型視頻或文件）時，速度較慢。
因為反向代理服務器工作在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服務器還是不夠出色。
五、直接路由( IP負載均衡-DR)
(LVS-DR Linux Virtual Server Direct Routing)
[鏈路層】數據鏈路層負載均衡
原理：在數據鏈路層修改Mac地址進行負載均衡。 
負載均衡服務器的IP和它所管理的web 服務群的虛擬IP一致；
負載均衡數據分發過程中不修改訪問地址的IP地址，而是修改Mac地址；
通過這兩點達到不修改數據包的原地址和目標地址就可以進行正常的訪問。
優點：不需要負載均衡服務器進行地址的轉換。
數據響應時不需要經過負載均衡服務器。
缺點：負載均衡服務器的網卡帶寬要求較高。
目前連路程負載均衡是特別常見的一種手段，典型的產品有LVS（Linux Virtual Server）。
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隧道 (IP負載均衡-Tunneling)(LVS-TUN Linux Virtaul Server Tunneling) [實際服務器和調度器可以不再同一個網段]
基於IP隧道的請求轉發機制：將調度器收到的IP數據包封裝在一個新的IP數據包中，轉交給實際服務器，然后實際服務器的響應數據包可以直接到達用戶端。目前Linux大多支持，可以用LVS來實現，稱為LVS-TUN，與LVS-DR不同的是，實際服務器可以和調度器不在同一個WANt網段，調度器通過IP隧道技術來轉發請求到實際服務器，所以實際服務器也必須擁有合法的IP地址。
總體來說，LVS-DR和LVS-TUN都適合響應和請求不對稱的Web服務器，如何從它們中做出選擇，取決於你的網絡部署需要，因為LVS-TUN可以將實際服務器根據需要部署在不同的地域，並且根據就近訪問的原則來轉移請求，所以有類似這種需求的，就應該選擇LVS-TUN。
參考：幾種負載均衡技術的實現