負載均衡原理
不能狹義地理解為分配給所有實際服務器一樣多的工作量，因為多台服務器的承載能力各不相同，這可能體現在硬件配置、網絡帶寬的差異，也可能因為某台服務器身兼多職，我們所說的“均衡”，也就是希望所有服務器都不要過載，並且能夠最大程序地發揮作用。
一、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。
https://my.oschina.net/u/3341316/blog/877206
LVS、Nginx 及 HAProxy 工作原理
LVS、Nginx、HAProxy 是目前使用最廣泛的三種軟件負載均衡軟件。
一般對負載均衡的使用是隨着網站規模的提升根據不同的階段來使用不同的技術。具體的應用需求還得具體分析，如果是中小型的 Web 應用，比如日 PV 小於1000萬，用 Nginx 就完全可以了；如果機器不少，可以用 DNS 輪詢，LVS 所耗費的機器還是比較多的；大型網站或重要的服務，且服務器比較多時，可以考慮用 LVS。
目前關於網站架構一般比較合理流行的架構方案：Web 前端采用 Nginx/HAProxy+Keepalived 作負載均衡器；后端采用 MySQ L數據庫一主多從和讀寫分離，采用 LVS+Keepalived 的架構。
LVS
LVS 是 Linux Virtual Server 的簡稱，也就是 Linux 虛擬服務器。現在 LVS 已經是 Linux 標准內核的一部分，從 Linux2.4 內核以后，已經完全內置了 LVS 的各個功能模塊，無需給內核打任何補丁，可以直接使用 LVS 提供的各種功能。
LVS 自從1998年開始，發展到現在已經是一個比較成熟的技術項目了。
LVS 的體系結構
LVS 架設的服務器集群系統有三個部分組成：
(1) 最前端的負載均衡層，用 Load Balancer 表示
(2) 中間的服務器集群層，用 Server Array 表示
(3) 最底端的數據共享存儲層，用 Shared Storage 表示
LVS 負載均衡機制
LVS 不像 HAProxy 等七層軟負載面向的是 HTTP 包，所以七層負載可以做的 URL 解析等工作，LVS 無法完成。
LVS 是四層負載均衡，也就是說建立在 OSI 模型的第四層——傳輸層之上，傳輸層上有我們熟悉的 TCP/UDP，LVS 支持 TCP/UDP 的負載均衡。因為 LVS 是四層負載均衡，因此它相對於其它高層負載均衡的解決辦法，比如 DNS 域名輪流解析、應用層負載的調度、客戶端的調度等，它的效率是非常高的。
所謂四層負載均衡 ，也就是主要通過報文中的目標地址和端口。七層負載均衡 ，也稱為“內容交換”，也就是主要通過報文中的真正有意義的應用層內容。
LVS 的轉發主要通過修改 IP 地址（NAT 模式，分為源地址修改 SNAT 和目標地址修改 DNAT）、修改目標 MAC（DR 模式）來實現。
NAT 模式：網絡地址轉換
NAT（Network Address Translation）是一種外網和內網地址映射的技術。
NAT 模式下，網絡數據報的進出都要經過 LVS 的處理。LVS 需要作為 RS（真實服務器）的網關。
當包到達 LVS 時，LVS 做目標地址轉換（DNAT），將目標 IP 改為 RS 的 IP。RS 接收到包以后，仿佛是客戶端直接發給它的一樣。RS 處理完，返回響應時，源 IP 是 RS IP，目標 IP 是客戶端的 IP。這時 RS 的包通過網關（LVS）中轉，LVS 會做源地址轉換（SNAT），將包的源地址改為 VIP，這樣，這個包對客戶端看起來就仿佛是 LVS 直接返回給它的。
LVS 的優點
- 抗負載能力強、是工作在傳輸層上僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟件里的性能最強的，對內存和 cpu 資源消耗比較低。
- 配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的幾率。
- 工作穩定，因為其本身抗負載能力很強，自身有完整的雙機熱備方案，如 LVS + Keepalived。
- 無流量，LVS 只分發請求，而流量並不從它本身出去，這點保證了均衡器 IO 的性能不會受到大流量的影響。
- 應用范圍比較廣，因為 LVS 工作在傳輸層，所以它幾乎可以對所有應用做負載均衡，包括 http、數據庫、在線聊天室等等。
LVS 的缺點
- 軟件本身不支持正則表達式處理，不能做動靜分離；而現在許多網站在這方面都有較強的需求，這個是 Nginx、HAProxy + Keepalived 的優勢所在。
- 如果是網站應用比較龐大的話，LVS/DR + Keepalived 實施起來就比較復雜了，相對而言，Nginx / HAProxy + Keepalived 就簡單多了。
Nginx 負載均衡
Nginx 負載均衡主要是對七層網絡通信模型中的第七層應用層上的 http、https 進行支持。
Nginx 是以反向代理的方式進行負載均衡的。反向代理（Reverse Proxy）方式是指以代理服務器來接受 Internet 上的連接請求，然后將請求轉發給內部網絡上的服務器，並將從服務器上得到的結果返回給 Internet 上請求連接的客戶端，此時代理服務器對外就表現為一個服務器。
Nginx 實現負載均衡的分配策略有很多，Nginx 的 upstream 目前支持以下幾種方式：
- 輪詢（默認）：每個請求按時間順序逐一分配到不同的后端服務器，如果后端服務器 down 掉，能自動剔除。
- weight：指定輪詢幾率，weight 和訪問比率成正比，用於后端服務器性能不均的情況。
- ip_hash：每個請求按訪問 ip 的 hash 結果分配，這樣每個訪客固定訪問一個后端服務器，可以解決 session 的問題。
- fair（第三方）：按后端服務器的響應時間來分配請求，響應時間短的優先分配。
- url_hash（第三方）：按訪問 url 的 hash 結果來分配請求，使每個 url 定向到同一個后端服務器，后端服務器為緩存時比較有效。
Nginx 的優點
- 跨平台：Nginx 可以在大多數 Unix like OS編譯運行，而且也有 Windows 的移植版本
- 配置異常簡單：非常容易上手。配置風格跟程序開發一樣，神一般的配置
- 非阻塞、高並發連接：官方測試能夠支撐5萬並發連接，在實際生產環境中跑到2～3萬並發連接數
- 事件驅動：通信機制采用 epoll 模型，支持更大的並發連接
- Master/Worker 結構：一個 master 進程，生成一個或多個 worker 進程
- 內存消耗小：處理大並發的請求內存消耗非常小。在3萬並發連接下，開啟的10個 Nginx 進程才消耗150M 內存（15M*10=150M）
- 內置的健康檢查功能：如果 Nginx 代理的后端的某台 Web 服務器宕機了，不會影響前端訪問
- 節省帶寬：支持 GZIP 壓縮，可以添加瀏覽器本地緩存的 Header 頭
- 穩定性高：用於反向代理，宕機的概率微乎其微
Nginx 的缺點
- Nginx 僅能支 持http、https 和 Email 協議，這樣就在適用范圍上面小些，這個是它的缺點
- 對后端服務器的健康檢查，只支持通過端口來檢測，不支持通過 ur l來檢測。不支持 Session 的直接保持，但能通過 ip_hash 來解決
HAProxy
HAProxy 支持兩種代理模式 TCP（四層）和HTTP（七層），也是支持虛擬主機的。
HAProxy 的優點能夠補充 Nginx 的一些缺點，比如支持 Session 的保持，Cookie 的引導；同時支持通過獲取指定的 url 來檢測后端服務器的狀態。
HAProxy 跟 LVS 類似，本身就只是一款負載均衡軟件；單純從效率上來講 HAProxy 會比 Nginx 有更出色的負載均衡速度，在並發處理上也是優於 Nginx 的。
HAProxy 支持 TCP 協議的負載均衡轉發，可以對 MySQL 讀進行負載均衡，對后端的 MySQL 節點進行檢測和負載均衡，大家可以用 LVS+Keepalived 對 MySQL 主從做負載均衡。
HAProxy 負載均衡策略非常多：Round-robin（輪循）、Weight-round-robin（帶權輪循）、source（原地址保持）、RI（請求URL）、rdp-cookie（根據cookie）。