摘要：面對大量用戶訪問、高并發請求，海量數據，可以使用高性能的服務器、大型數據庫，存儲設備，高性能Web服務器，采用高效率的編程語言比如(Go,Scala)等...
面對大量用戶訪問、高并發請求，海量數據，可以使用高性能的服務器、大型數據庫，存儲設備，高性能Web服務器，采用高效率的編程語言比如(Go,Scala)等，當單機容量達到極限時，我們需要考慮業務拆分和分布式部署，來解決大型網站訪問量大，并發量高，海量數據的問題。
從單機網站到分布式網站，很重要的區別是業務拆分和分布式部署，將應用拆分后，部署到不同的機器上，實現大規模分布式系統。分布式和業務拆分解決了，從集中到分布的問題，但是每個部署的獨立業務還存在單點的問題和訪問統一入口問題，為解決單點故障，我們可以采取冗余的方式。將相同的應用部署到多臺機器上。解決訪問統一入口問題，我們可以在集群前面增加負載均衡設備，實現流量分發。
負載均衡（Load Balance），意思是將負載（工作任務，訪問請求）進行平衡、分攤到多個操作單元（服務器，組件）上進行執行。是解決高性能，單點故障（高可用），擴展性（水平伸縮）的終極解決方案。
本文是負載均衡詳解的第一篇文章，介紹負載均衡的原理，負載均衡分類（DNS負載均衡,HTTP負載均衡，IP負載均衡，鏈路層負載均衡,混合型P負載均衡）。部分內容摘自讀書筆記。
大綱
負載均衡原理
DNS負載均衡
HTTP負載均衡
IP負載均衡
鏈路層負載均衡
混合型P負載均衡
一、負載均衡原理
系統的擴展可分為縱向（垂直）擴展和橫向（水平）擴展。縱向擴展，是從單機的角度通過增加硬件處理能力，比如CPU處理能力，內存容量，磁盤等方面，實現服務器處理能力的提升，不能滿足大型分布式系統（網站），大流量，高并發，海量數據的問題。因此需要采用橫向擴展的方式，通過添加機器來滿足大型網站服務的處理能力。比如：一臺機器不能滿足，則增加兩臺或者多臺機器，共同承擔訪問壓力。這就是典型的集群和負載均衡架構：如下圖：
應用集群：將同一應用部署到多臺機器上，組成處理集群，接收負載均衡設備分發的請求，進行處理，并返回相應數據。
負載均衡設備：將用戶訪問的請求，根據負載均衡算法，分發到集群中的一臺處理服務器。（一種把網絡請求分散到一個服務器集群中的可用服務器上去的設備）
負載均衡的作用（解決的問題）：
1.解決并發壓力，提高應用處理性能（增加吞吐量，加強網絡處理能力）；
2.提供故障轉移，實現高可用；
3.通過添加或減少服務器數量，提供網站伸縮性（擴展性）；
4.安全防護；（負載均衡設備上做一些過濾，黑白名單等處理）
二、負載均衡分類
根據實現技術不同，可分為DNS負載均衡，HTTP負載均衡，IP負載均衡，鏈路層負載均衡等。
2.1DNS負載均衡
最早的負載均衡技術，利用域名解析實現負載均衡，在DNS服務器，配置多個A記錄，這些A記錄對應的服務器構成集群。大型網站總是部分使用DNS解析，作為第一級負載均衡。如下圖：
優點
使用簡單：負載均衡工作，交給DNS服務器處理，省掉了負載均衡服務器維護的麻煩
提高性能：可以支持基于地址的域名解析，解析成距離用戶最近的服務器地址，可以加快訪問速度，改善性能；
缺點
可用性差：DNS解析是多級解析，新增/修改DNS后，解析時間較長；解析過程中，用戶訪問網站將失敗；
擴展性低：DNS負載均衡的控制權在域名商那里，無法對其做更多的改善和擴展；
維護性差：也不能反映服務器的當前運行狀態；支持的算法少；不能區分服務器的差異（不能根據系統與服務的狀態來判斷負載）
實踐建議
將DNS作為第一級負載均衡，A記錄對應著內部負載均衡的IP地址，通過內部負載均衡將請求分發到真實的Web服務器上。一般用于互聯網公司，復雜的業務系統不合適使用。如下圖：
2.3 IP負載均衡
在網絡層通過修改請求目標地址進行負載均衡。
用戶請求數據包，到達負載均衡服務器后，負載均衡服務器在操作系統內核進程獲取網絡數據包，根據負載均衡算法得到一臺真實服務器地址，然后將請求目的地址修改為，獲得的真實ip地址，不需要經過用戶進程處理。
真實服務器處理完成后，響應數據包回到負載均衡服務器，負載均衡服務器，再將數據包源地址修改為自身的ip地址，發送給用戶瀏覽器。如下圖：
IP負載均衡，真實物理服務器返回給負載均衡服務器，存在兩種方式：
（1）負載均衡服務器在修改目的ip地址的同時修改源地址。將數據包源地址設為自身盤，即源地址轉換（snat）。
（2）將負載均衡服務器同時作為真實物理服務器集群的網關服務器。
優點：
（1）在內核進程完成數據分發，比在應用層分發性能更好；
缺點：
（2）所有請求響應都需要經過負載均衡服務器，集群最大吞吐量受限于負載均衡服務器網卡帶寬；
2.4 鏈路層負載均衡
在通信協議的數據鏈路層修改mac地址，進行負載均衡。
數據分發時，不修改ip地址，指修改目標mac地址，配置真實物理服務器集群所有機器虛擬ip和負載均衡服務器ip地址一致，達到不修改數據包的源地址和目標地址，進行數據分發的目的。
實際處理服務器ip和數據請求目的ip一致，不需要經過負載均衡服務器進行地址轉換，可將響應數據包直接返回給用戶瀏覽器，避免負載均衡服務器網卡帶寬成為瓶頸。也稱為直接路由模式（DR模式）。如下圖：
優點：性能好；
缺點：配置復雜；
實踐建議：DR模式是目前使用最廣泛的一種負載均衡方式。
2.5 混合型負載均衡
由于多個服務器群內硬件設備、各自的規模、提供的服務等的差異，可以考慮給每個服務器群采用最合適的負載均衡方式，然后又在這多個服務器群間再一次負載均衡或群集起來以一個整體向外界提供服務（即把這多個服務器群當做一個新的服務器群），從而達到最佳的性能。將這種方式稱之為混合型負載均衡。
此種方式有時也用于單臺均衡設備的性能不能滿足大量連接請求的情況下。是目前大型互聯網公司，普遍使用的方式。
方式一，如下圖：
以上模式適合有動靜分離的場景，反向代理服務器（集群）可以起到緩存和動態請求分發的作用，當時靜態資源緩存在代理服務器時，則直接返回到瀏覽器。如果動態頁面則請求后面的應用負載均衡（應用集群）。
方式二，如下圖：
以上模式，適合動態請求場景。
因混合模式，可以根據具體場景，靈活搭配各種方式，以上兩種方式僅供參考。
分享是快樂的，也是個人成長的過程。
三、負載均衡算法
常用的負載均衡算法有，輪詢，隨機，最少鏈接，源地址散列，加權等方式；
3.1 輪詢
將所有請求，依次分發到每臺服務器上，適合服務器硬件同相同的場景。
優點：服務器請求數目相同；
缺點：服務器壓力不一樣，不適合服務器配置不同的情況；
3.2 隨機
請求隨機分配到各個服務器。
優點：使用簡單；
缺點：不適合機器配置不同的場景；
3.3 最少鏈接
將請求分配到連接數最少的服務器（目前處理請求最少的服務器）。
優點：根據服務器當前的請求處理情況，動態分配；
缺點：算法實現相對復雜，需要監控服務器請求連接數；
3.4 Hash（源地址散列）
根據IP地址進行Hash計算，得到IP地址。
優點：將來自同一IP地址的請求，同一會話期內，轉發到相同的服務器；實現會話粘滯。
缺點：目標服務器宕機后，會話會丟失；
3.5 加權
在輪詢，隨機，最少鏈接，Hash’等算法的基礎上，通過加權的方式，進行負載服務器分配。
優點：根據權重，調節轉發服務器的請求數目；
缺點：使用相對復雜；
四、硬件負載均衡
采用硬件的方式實現負載均衡，一般是單獨的負載均衡服務器，價格昂貴，一般土豪級公司可以考慮，業界領先的有兩款，F5和A10。
使用硬件負載均衡，主要考慮一下幾個方面：
（1）功能考慮：功能全面支持各層級的負載均衡，支持全面的負載均衡算法，支持全局負載均衡；
（2）性能考慮：一般軟件負載均衡支持到5萬級并發已經很困難了，硬件負載均衡可以支持
（3）穩定性：商用硬件負載均衡，經過了良好的嚴格的測試，從經過大規模使用，在穩定性方面高；
（4）安全防護：硬件均衡設備除具備負載均衡功能外，還具備防火墻，防DDOS攻擊等安全功能；
（5）維護角度：提供良好的維護管理界面，售后服務和技術支持；
（6）土豪公司：F5 Big Ip 價格：15w~55w不等；A10 價格：55w-100w不等；
缺點
1）價格昂貴；
2）擴展能力差；
小結
（1）一般硬件的負載均衡也要做雙機高可用，因此成本會比較高。
（2）互聯網公司一般使用開源軟件，因此大部分應用采用軟件負載均衡；部分采用硬件負載均衡。
比如某互聯網公司，目前是使用幾臺F5做全局負載均衡，內部使用Nginx等軟件負載均衡。
五、總結
以上主要從負載均衡原理，分類，算法，硬件負載均衡進行了介紹。下次分享，負載均衡詳解（三），主要介紹：軟件負載均衡（LVS,Nginx，Haproxy，Apache特點，架構），負載均衡軟件技術選型比較，應用負載均衡的問題和解決方案等方面。
摘要：硬件負載均衡性能優越，功能全面，但是價格昂貴，一般適合初期或者土豪級公司長期使用。因此軟件負載均衡在互聯網領域大量使用...
大綱
軟件負載均衡概述
Ngnix負載均衡
Lvs負載均衡
Haproxy負載均衡
本次分享總結
一、軟件負載均衡概述
硬件負載均衡性能優越，功能全面，但是價格昂貴，一般適合初期或者土豪級公司長期使用。因此軟件負載均衡在互聯網領域大量使用。常用的軟件負載均衡軟件有Nginx，Lvs，HaProxy等。本文參考大量文檔，部分為直接拷貝，參考出處見負載均衡詳解（4）。
二、Ngnix負載均衡
Ngnix是一款輕量級的Web服務器/反向代理服務器，工作在七層Http協議的負載均衡系統。具有高性能、高并發、低內存使用等特點。是一個輕量級的Http和反向代理服務器。Nginx使用epoll and kqueue作為開發模型。能夠支持高達 50,000 個并發連接數的響應。
操作系統：Liunx，Windows（Linux、FreeBSD、Solaris、Mac OS X、AIX以及Microsoft Windows）
開發語言：C
并發性能：官方支持每秒5萬并發，實際國內一般到每秒2萬并發，有優化到每秒10萬并發的。具體性能看應用場景。
2.1.特點
1.模塊化設計：良好的擴展性，可以通過模塊方式進行功能擴展。
2.高可靠性：主控進程和worker是同步實現的，一個worker出現問題，會立刻啟動另一個worker。
3.內存消耗低：一萬個長連接（keep-alive）,僅消耗2.5MB內存。
4.支持熱部署：不用停止服務器，實現更新配置文件，更換日志文件、更新服務器程序版本。
5.并發能力強：官方數據每秒支持5萬并發；
6.功能豐富：優秀的反向代理功能和靈活的負載均衡策略
2.2.功能
2.2.1基本功能
支持靜態資源的web服務器。
http,smtp,pop3協議的反向代理服務器、緩存、負載均衡；
支持FASTCGI（fpm）
支持模塊化，過濾器（讓文本可以實現壓縮，節約帶寬）,ssl及圖像大小調整。
內置的健康檢查功能
基于名稱和ip的虛擬主機
定制訪問日志
支持平滑升級
支持KEEPALIVE
支持url rewrite
支持路徑別名
支持基于IP和用戶名的訪問控制。
支持傳輸速率限制，支持并發數限制。
2.2.2擴展功能
2.2.3性能
Nginx的高并發，官方測試支持5萬并發連接。實際生產環境能到2-3萬并發連接數。10000個非活躍的HTTP keep-alive 連接僅占用約2.5MB內存。三萬并發連接下，10個Nginx進程，消耗內存150M。淘寶tengine團隊測試結果是“24G內存機器上，處理并發請求可達200萬”。
2.3架構
2.3.1 Nginx的基本工作模式
一個master進程，生成一個或者多個worker進程。但是這里master是使用root身份啟動的，因為nginx要工作在80端口。而只有管理員才有權限啟動小于低于1023的端口。master主要是負責的作用只是啟動worker，加載配置文件，負責系統的平滑升級。其它的工作是交給worker。那么當worker被啟動之后，也只是負責一些web最簡單的工作，而其他的工作都是有worker中調用的模塊來實現的。
模塊之間是以流水線的方式實現功能的。流水線，指的是一個用戶請求，由多個模塊組合各自的功能依次實現完成的。比如：第一個模塊只負責分析請求首部，第二個模塊只負責查找數據，第三個模塊只負責壓縮數據，依次完成各自工作。來實現整個工作的完成。
他們是如何實現熱部署的呢？其實是這樣的，我們前面說master不負責具體的工作，而是調用worker工作，他只是負責讀取配置文件，因此當一個模塊修改或者配置文件發生變化，是由master進行讀取，因此此時不會影響到worker工作。在master進行讀取配置文件之后，不會立即的把修改的配置文件告知worker。而是讓被修改的worker繼續使用老的配置文件工作，當worker工作完畢之后，直接當掉這個子進程，更換新的子進程，使用新的規則。
2.3.2Nginx支持的sendfile機制
Sendfile機制，用戶將請求發給內核，內核根據用戶的請求調用相應用戶進程，進程在處理時需要資源。此時再把請求發給內核（進程沒有直接IO的能力），由內核加載數據。內核查找到數據之后，會把數據復制給用戶進程，由用戶進程對數據進行封裝，之后交給內核，內核在進行tcp/ip首部的封裝，最后再發給客戶端。這個功能用戶進程只是發生了一個封裝報文的過程，卻要繞一大圈。因此nginx引入了sendfile機制，使得內核在接受到數據之后，不再依靠用戶進程給予封裝，而是自己查找自己封裝，減少了一個很長一段時間的浪費，這是一個提升性能的核心點。
以上內容摘自網友發布的文章，簡單一句話是資源的處理，直接通過內核層進行數據傳遞，避免了數據傳遞到應用層，應用層再傳遞到內核層的開銷。
目前高并發的處理，一般都采用sendfile模式。通過直接操作內核層數據，減少應用與內核層數據傳遞。
2.3.3Nginx通信模型（I/O復用機制）
開發模型：epoll和kqueue。
支持的事件機制：kqueue、epoll、rt signals、/dev/poll 、event ports、select以及poll。
支持的kqueue特性包括EV_CLEAR、EV_DISABLE、NOTE_LOWAT、EV_EOF，可用數據的數量，錯誤代碼.
支持sendfile、sendfile64和sendfilev;文件AIO；DIRECTIO;支持Accept-filters和TCP_DEFER_ACCEP.
以上概念較多，大家自行百度或谷歌，知識領域是網絡通信（BIO,NIO,AIO）和多線程方面的知識。
2.4均衡策略
nginx的負載均衡策略可以劃分為兩大類：內置策略和擴展策略。內置策略包含加權輪詢和ip hash，在默認情況下這兩種策略會編譯進nginx內核，只需在nginx配置中指明參數即可。擴展策略有很多，如fair、通用hash、consistent hash等，默認不編譯進nginx
內核。由于在nginx版本升級中負載均衡的代碼沒有本質性的變化，因此下面將以nginx1.0.15穩定版為例，從源碼角度分析各個策略。
2.4.1. 加權輪詢（weighted round robin）
輪詢的原理很簡單，首先我們介紹一下輪詢的基本流程。如下是處理一次請求的流程圖：
圖中有兩點需要注意，第一，如果可以把加權輪詢算法分為先深搜索和先廣搜索，那么nginx采用的是先深搜索算法，即將首先將請求都分給高權重的機器，直到該機器的權值降到了比其他機器低，才開始將請求分給下一個高權重的機器；第二，當所有后端機器都down掉時，nginx會立即將所有機器的標志位清成初始狀態，以避免造成所有的機器都處在timeout的狀態，從而導致整個前端被夯住。
2.4.2. ip hash
ip hash是nginx內置的另一個負載均衡的策略，流程和輪詢很類似，只是其中的算法和具體的策略有些變化，如下圖所示：
2.4.3. fair
fair策略是擴展策略，默認不被編譯進nginx內核。其原理是根據后端服務器的響應時間判斷負載情況，從中選出負載最輕的機器進行分流。這種策略具有很強的自適應性，但是實際的網絡環境往往不是那么簡單，因此要慎用。
2.4.4 通用hash、一致性hash
這兩種也是擴展策略，在具體的實現上有些差別，通用hash比較簡單，可以以nginx內置的變量為key進行hash，一致性hash采用了nginx內置的一致性hash環，可以支持memcache。
2.5場景
Ngnix一般作為入口負載均衡或內部負載均衡，結合反向代理服務器使用。以下架構示例，僅供參考，具體使用根據場景而定。
2.5.1入口負載均衡架構
！
Ngnix服務器在用戶訪問的最前端。根據用戶請求再轉發到具體的應用服務器或二級負載均衡服務器（LVS）
2.5.2內部負載均衡架構
LVS作為入口負載均衡，將請求轉發到二級Ngnix服務器，Ngnix再根據請求轉發到具體的應用服務器。
2.5.3Ngnix高可用
分布式系統中，應用只部署一臺服務器會存在單點故障，負載均衡同樣有類似的問題。一般可采用主備或負載均衡設備集群的方式節約單點故障或高并發請求分流。
Ngnix高可用，至少包含兩個Ngnix服務器，一臺主服務器，一臺備服務器，之間使用Keepalived做健康監控和故障檢測。開放VIP端口，通過防火墻進行外部映射。
DNS解析公網的IP實際為VIP。
