我還寫了兩篇詳細的html
參考：六大Web負載均衡原理與實現web
參考：LVS(Linus Virtual Server)：三種IP負載均衡方式比較+另三種Web負載均衡方式面試
其中LVS、HAProxy能夠工做在4-7層，NginX工做在7層(阿里面試題)redis
Web負載均衡的幾種實現方式
摘要：
負載均衡(Load Balance)是集羣技術（Cluster）的一種應用。負載均衡能夠將工做任務分攤到多個處理單元，從而提升併發處理能力。目前最多見的負載均衡應用是Web負載均衡。根據實現的原理不一樣，常見的web負載均衡技術包括：DNS輪詢、IP負載均衡和CDN。其中IP負載均衡可使用硬件設備或軟件方式來實現。後端
什麼是web負載均衡
服務器集羣(Cluster)使得多個服務器節點可以協同工做，根據目的的不一樣，服務器集羣能夠分爲：瀏覽器
高性能集羣：將單個重負載的請求分散到多個節點進行處理，最後再將處理結果進行彙總
高可用集羣：提升冗餘單元，避免單點故障
負載均衡集羣：將大量的併發請求分擔到多個處理節點。因爲單個處理節點的故障不影響整個服務，負載均衡集羣同時也實現了高可用性。
通常提到的負載均衡(Load Balance)，是指實現負載均衡集羣。負載均衡實現了橫向擴展，避免縱向的升級換代。緩存
本文中的web負載均衡，特指可以分擔web請求（http，https等）的負載均衡技術。安全
基本原理
任何的負載均衡技術都要想辦法創建某種一對多的映射機制: 一個請求的入口映射到多個處理請求的節點，從而實現分而治之（Divide and Conquer）。服務器
這種映射機制使得多個物理存在對外體現爲一個虛擬的總體，對服務的請求者屏蔽了內部的結構。cookie
採用不一樣的機制創建映射關係，能夠造成不一樣的負載均衡技術，常見的包括：
(a)DNS輪詢 (b) CDN加速(c) IP負載均衡
DNS輪詢
DNS輪詢是最簡單的負載均衡方式。以域名做爲訪問入口，經過配置多條DNS A記錄使得請求能夠分配到不一樣的服務器。
DNS輪詢沒有快速的健康檢查機制，並且只支持WRR的調度策略致使負載很難「均衡」，一般用於要求不高的場景。 而且DNS輪詢方式直接將服務器的真實地址暴露給用戶，不利於服務器安全。
DNS負載均衡技術的實現原理是在DNS服務器中爲同一個主機名配置多個IP地址，在應答DNS查詢時，DNS服務器對每一個查詢將以DNS文件中主機記錄的IP地址按順序返回不一樣的解析結果，將客戶端的訪問引導到不一樣的機器上去，使得不一樣的客戶端訪問不一樣的服務器，從而達到負載均衡的目的。
CDN
CDN（Content Delivery Network，內容分發網絡）。經過發佈機制將內容同步到大量的緩存節點，並在DNS服務器上進行擴展， 找到裏用戶最近的緩存節點做爲服務提供節點。
由於很難自建大量的緩存節點，因此一般使用CDN運營商的服務。目前國內的服務商不多，並且按流量計費，價格也比較昂貴。
IP負載均衡
IP負載均衡是基於特定的TCP/IP技術實現的負載均衡。好比NAT、DR、Tunneling等。是最常用的方式。 關於其原理，能夠參考另外一篇文章：LVS(Linus Virtual Server)：三種IP負載均衡方式比較+另三種Web負載均衡方式。
IP負載均衡可使用硬件設備，也可使用軟件實現。硬件設備的主要產品是F5-BIG-IP-GTM（簡稱F5)， 軟件產品主要有LVS、HAProxy、NginX。其中LVS、HAProxy能夠工做在4-7層，NginX工做在7層(阿里面試題)。關於三者的簡單對比，能夠參考這裏。
硬件負載均衡設備能夠將核心部分作成芯片，性能和穩定性更好，並且商用產品的可管理性、文檔和服務都比較好。惟一的問題就是價格。
軟件負載均衡一般是開源軟件。自由度較高，但學習成本和管理成本會比較大。
當一個Web系統從日訪問量10萬逐步增加到1000萬，甚至超過1億的過程當中，Web系統承受的壓力會愈來愈大，在這個過程當中，咱們會遇到不少的問題。爲了解決這些性能壓力帶來問題，咱們須要經過搭建不一樣的服務和架構來解決。
當單機容量達到極限時，咱們須要考慮業務拆分和分佈式部署，來解決大型網站訪問量大，併發量高，海量數據的問題。從單機到分佈式，很重要的區別是業務拆分和分佈式部署，將應用拆分後，部署到不一樣的機器上，實現大規模分佈式系統。分佈式和業務拆分解決了，從集中到分佈的問題，可是每一個部署的獨立業務還存在單點的問題和訪問統一入口問題，爲解決單點故障，咱們能夠採起冗餘的方式。將相同的應用部署到多臺機器上。解決訪問統一入口問題，咱們能夠在集羣前面增長負載均衡設備，實現流量分發。
Web負載均衡（Load Balancing），
簡單地說就是將負載（工做任務，訪問請求）進行平衡、分攤到多個操做單元（服務器，組件）上進行執行。對於保護處於後端的Web服務器來講，很是重要，是解決高性能，單點故障（高可用），擴展性（水平伸縮）的終極解決方案。
負載均衡的策略有不少，咱們從簡單的講起哈。
一、HTTP負載均衡
當用戶發來請求的時候，Web服務器經過修改HTTP響應頭中的Location標記來返回一個新的url，而後瀏覽器再繼續請求這個新url，實際上就是頁面重定向。經過重定向，來達到「負載均衡」的目標。例如，咱們在下載PHP源碼包的時候，點擊下載連接時，爲了解決不一樣國家和地域下載速度的問題，它會返回一個離咱們近的下載地址。重定向的HTTP返回碼是302，以下圖：
若是使用PHP代碼來實現這個功能，方式以下：
這個重定向很是容易實現，而且能夠自定義各類策略。可是，它在大規模訪問量下，性能不佳。並且，給用戶的體驗也很差，實際請求發生重定向，增長了網絡延時。
二、反向代理負載均衡
參考：反向代理-銀行系統使用，在防火牆外面放代理服務器，在防火牆裏面放上真正的內容服務器
反向代理服務的核心工做主要是轉發HTTP請求，扮演了瀏覽器端和後臺Web服務器中轉的角色。由於它工做在HTTP層（應用層），也就是網絡七層結構中的第七層，所以也被稱爲「七層負載均衡」。能夠作反向代理的軟件不少，比較常見的一種是Nginx。
Nginx是一種很是靈活的反向代理軟件，能夠自由定製化轉發策略，分配服務器流量的權重等。反向代理中，常見的一個問題，就是Web服務器存儲的session數據，由於通常負載均衡的策略都是隨機分配請求的。同一個登陸用戶的請求，沒法保證必定分配到相同的Web機器上，會致使沒法找到session的問題。
解決方案主要有兩種：
a) 配置反向代理的轉發規則，讓同一個用戶的請求必定落到同一臺機器上（經過分析cookie），複雜的轉發規則將會消耗更多的CPU，也增長了代理服務器的負擔。
b) 將session這類的信息，專門用某個獨立服務來存儲，例如redis/memchache，這個方案是比較推薦的。
反向代理服務，也是能夠開啓緩存的，若是開啓了，會增長反向代理的負擔，須要謹慎使用。這種負載均衡策略實現和部署很是簡單，並且性能表現也比較好。可是，它有「單點故障」的問題，若是掛了，會帶來不少的麻煩。並且，到了後期Web服務器繼續增長，它自己可能成爲系統的瓶頸。
三、DNS負載均衡
DNS（Domain Name System）負責域名解析的服務，域名url其實是服務器的別名，實際映射是一個IP地址，解析過程，就是DNS完成域名到IP的映射。而一個域名是能夠配置成對應多個IP的。所以，DNS也就能夠做爲負載均衡服務。
這種負載均衡策略，配置簡單，性能極佳。可是，不能自由定義規則，並且，變動被映射的IP或者機器故障時很麻煩，還存在DNS生效延遲的問題。
四、CDN(Content Delivery Network) 內容分發網絡 (DNS/GSLB負載均衡)
參考：CDN加速-內容分發網絡
咱們經常使用的CDN（Content Delivery Network，內容分發網絡）實現方式，其實就是在同一個域名映射爲多IP的基礎上更進一步，經過GSLB（Global Server Load Balance，全局負載均衡）按照指定規則映射域名的IP。通常狀況下都是按照地理位置，將離用戶近的IP返回給用戶，減小網絡傳輸中的路由節點之間的跳躍消耗。
圖中的「向上尋找」，實際過程是LDNS（Local DNS）先向根域名服務（Root Name Server）獲取到頂級根的Name Server（例如.com的），而後獲得指定域名的受權DNS，而後再得到實際服務器IP。
CDN在Web系統中，通常狀況下是用來解決大小較大的靜態資源（html/Js/Css/圖片等）的加載問題，讓這些比較依賴網絡下載的內容，儘量離用戶更近，提高用戶體驗。
例如，我訪問了一張imgcache.gtimg.cn上的圖片（騰訊的自建CDN，不使用qq.com域名的緣由是防止http請求的時候，帶上了多餘的cookie信息），我得到的IP是183.60.217.90。
這種方式，和前面的DNS負載均衡同樣，不只性能極佳，並且支持配置多種策略。可是，搭建和維護成本很是高。互聯網一線公司，會自建CDN服務，中小型公司通常使用第三方提供的CDN。
IP負載均衡
IP負載均衡服務是工做在網絡層（修改IP）和傳輸層（修改端口，第四層），比起工做在應用層（第七層）性能要高出很是多。原理是，他是對IP層的數據包的IP地址和端口信息進行修改，達到負載均衡的目的。這種方式，也被稱爲「四層負載均衡」。常見的負載均衡方式，是LVS（Linux Virtual Server，Linux虛擬服務），經過IPVS（IP Virtual Server，IP虛擬服務）來實現。
在負載均衡服務器收到客戶端的IP包的時候，會修改IP包的目標IP地址或端口，而後原封不動地投遞到內部網絡中，數據包會流入到實際Web服務器。實際服務器處理完成後，又會將數據包投遞迴給負載均衡服務器，它再修改目標IP地址爲用戶IP地址，最終回到客戶端。
上述的方式叫LVS-NAT，除此以外，還有LVS-RD（直接路由），LVS-TUN（IP隧道），三者之間都屬於LVS的方式，可是有必定的區別，篇幅問題，不贅敘。
IP負載均衡的性能要高出Nginx的反向代理不少，它只處理到傳輸層爲止的數據包，並不作進一步的組包，而後直接轉發給實際服務器。不過，它的配置和搭建比較複雜。