一、軟體負載均衡概述
硬體負載均衡效能優越，功能全面，但是價格昂貴，一般適合初期或者土豪級公司長期使用。因此軟體負載均衡在網際網路領域大量使用。常用的軟體負載均衡軟體有Nginx，Lvs，HaProxy等。本文參考大量文件，部分為直接拷貝，參考出處文末。
二、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.1Nginx的基本工作模式
一個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。
三、LVS負載均衡
LVS是一個開源的軟體，由畢業於國防科技大學的章文嵩博士於1998年5月創立，用來實現Linux平臺下的簡單負載均衡。LVS是Linux Virtual Server的縮寫，意思是Linux虛擬伺服器。
基於IP層的負載均衡排程技術，它在作業系統核心層上，將來自IP層的TCP/UDP請求均衡地轉移到不同的 伺服器，從而將一組伺服器構成一個高效能、高可用的虛擬伺服器。
作業系統：Liunx
開發語言：C
併發效能：預設4096，可以修改但需要重新編譯。
3.1.功能
LVS的主要功能是實現IP層（網路層）負載均衡，有NAT,TUN,DR三種請求轉發模式。
3.1.1LVS/NAT方式的負載均衡叢集
NAT是指Network Address Translation，它的轉發流程是：Director機器收到外界請求，改寫資料包的目標地址，按相應的排程演算法將其傳送到相應Real Server上，Real Server處理完該請求後，將結果資料包返回到其預設閘道器，即Director機器上，Director機器再改寫資料包的源地址，最後將其返回給外界。這樣就完成一次負載排程。
構架一個最簡單的LVS/NAT方式的負載均衡叢集Real Server可以是任何的作業系統，而且無需做任何特殊的設定，惟一要做的就是將其預設閘道器指向Director機器。Real Server可以使用區域網的內部IP(192.168.0.0/24)。Director要有兩塊網路卡，一塊網路卡繫結一個外部IP地址 (10.0.0.1)，另一塊網路卡繫結區域網的內部IP(192.168.0.254)，作為Real Server的預設閘道器。
LVS/NAT方式實現起來最為簡單，而且Real Server使用的是內部IP，可以節省Real IP的開銷。但因為執行NAT需要重寫流經Director的資料包，在速度上有一定延遲；
當使用者的請求非常短，而伺服器的迴應非常大的情況下，會對Director形成很大壓力，成為新的瓶頸，從而使整個系統的效能受到限制。
3.1.2LVS/TUN方式的負載均衡叢集
TUN是指IP Tunneling，它的轉發流程是：Director機器收到外界請求，按相應的排程演算法,通過IP隧道傳送到相應Real Server，Real Server處理完該請求後，將結果資料包直接返回給客戶。至此完成一次負載排程。
最簡單的LVS/TUN方式的負載均衡叢集架構使用IP Tunneling技術，在Director機器和Real Server機器之間架設一個IP Tunnel，通過IP Tunnel將負載分配到Real Server機器上。Director和Real Server之間的關係比較鬆散，可以是在同一個網路中，也可以是在不同的網路中，只要兩者能夠通過IP Tunnel相連就行。收到負載分配的Real Server機器處理完後會直接將反饋資料送回給客戶，而不必通過Director機器。實際應用中，伺服器必須擁有正式的IP地址用於與客戶機直接通訊，並且所有伺服器必須支援IP隧道協議。
該方式中Director將客戶請求分配到不同的Real Server，Real Server處理請求後直接回應給使用者，這樣Director就只處理客戶機與伺服器的一半連線，極大地提高了Director的排程處理能力，使叢集系統能容納更多的節點數。另外TUN方式中的Real Server可以在任何LAN或WAN上執行，這樣可以構築跨地域的叢集，其應對災難的能力也更強，但是伺服器需要為IP封裝付出一定的資源開銷，而且後端的Real Server必須是支援IP Tunneling的作業系統。
3.3.3LVS/TUN方式的負載均衡叢集
DR是指Direct Routing，它的轉發流程是：Director機器收到外界請求，按相應的排程演算法將其直接傳送到相應Real Server，Real Server處理完該請求後，將結果資料包直接返回給客戶，完成一次負載排程。
構架一個最簡單的LVS/DR方式的負載均衡叢集Real Server和Director都在同一個物理網段中，Director的網路卡IP是192.168.0.253，再繫結另一個IP： 192.168.0.254作為對外界的virtual IP，外界客戶通過該IP來訪問整個叢集系統。Real Server在lo上繫結IP：192.168.0.254，同時加入相應的路由。
LVS/DR方式與前面的LVS/TUN方式有些類似，前臺的Director機器也是隻需要接收和排程外界的請求，而不需要負責返回這些請求的反饋結果，所以能夠負載更多的Real Server，提高Director的排程處理能力，使叢集系統容納更多的Real Server。但LVS/DR需要改寫請求報文的MAC地址，所以所有伺服器必須在同一物理網段內。
3.3架構
LVS架設的伺服器叢集系統有三個部分組成：最前端的負載均衡層（Loader Balancer），中間的伺服器群組層，用Server Array表示，最底層的資料共享儲存層，用Shared Storage表示。在使用者看來所有的應用都是透明的，使用者只是在使用一個虛擬伺服器提供的高效能服務。
LVS的體系架構如圖：
LVS的各個層次的詳細介紹：
Load Balancer層：位於整個叢集系統的最前端，有一臺或者多臺負載排程器（Director Server）組成，LVS模組就安裝在Director Server上，而Director的主要作用類似於一個路由器，它含有完成LVS功能所設定的路由表，通過這些路由表把使用者的請求分發給Server Array層的應用伺服器（Real Server）上。同時，在Director Server上還要安裝對Real Server服務的監控模組Ldirectord，此模組用於監測各個Real Server服務的健康狀況。在Real Server不可用時把它從LVS路由表中剔除，恢復時重新加入。
Server Array層：由一組實際執行應用服務的機器組成，Real Server可以是WEB伺服器、MAIL伺服器、FTP伺服器、DNS伺服器、視訊伺服器中的一個或者多個，每個Real Server之間通過高速的LAN或分佈在各地的WAN相連線。在實際的應用中，Director Server也可以同時兼任Real Server的角色。
Shared Storage層：是為所有Real Server提供共享儲存空間和內容一致性的儲存區域，在物理上，一般有磁碟陣列裝置組成，為了提供內容的一致性，一般可以通過NFS網路檔案系統共享數 據，但是NFS在繁忙的業務系統中，效能並不是很好，此時可以採用叢集檔案系統，例如Red hat的GFS檔案系統，oracle提供的OCFS2檔案系統等。
從整個LVS結構可以看出，Director Server是整個LVS的核心，目前，用於Director Server的作業系統只能是Linux和FreeBSD，linux2.6核心不用任何設定就可以支援LVS功能，而FreeBSD作為 Director Server的應用還不是很多，效能也不是很好。對於Real Server，幾乎可以是所有的系統平臺，Linux、windows、Solaris、AIX、BSD系列都能很好的支援。
3.4均衡策略
LVS預設支援八種負載均衡策略，簡述如下：
3.4.1.輪詢排程（Round Robin）
排程器通過“輪詢”排程演算法將外部請求按順序輪流分配到叢集中的真實伺服器上，它均等地對待每一臺伺服器，而不管伺服器上實際的連線數和系統負載。
3.4.2.加權輪詢（Weighted Round Robin）
排程器通過“加權輪詢”排程演算法根據真實伺服器的不同處理能力來排程訪問請求。這樣可以保證處理能力強的伺服器能處理更多的訪問流量。排程器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。
3.4.3.最少連結（Least Connections）
排程器通過“最少連線”排程演算法動態地將網路請求排程到已建立的連結數最少的伺服器上。如果叢集系統的真實伺服器具有相近的系統效能，採用“最小連線”排程演算法可以較好地均衡負載。
3.4.4.加權最少連結（Weighted Least Connections）
在叢集系統中的伺服器效能差異較大的情況下，排程器採用“加權最少連結”排程演算法優化負載均衡效能，具有較高權值的伺服器將承受較大比例的活動連線負載。排程器可以自動問詢真實伺服器的負載情況，並動態地調整其權值。
3.4.5.基於區域性性的最少連結（Locality-Based Least Connections）
“基於區域性性的最少連結”排程演算法是針對目標IP地址的負載均衡，目前主要用於Cache叢集系統。該演算法根據請求的目標IP地址找出該目標IP地址最近使用的伺服器，若該伺服器是可用的且沒有超載，將請求傳送到該伺服器；若伺服器不存在，或者該伺服器超載且有伺服器處於一半的工作負載，則用“最少連結” 的原則選出一個可用的伺服器，將請求傳送到該伺服器。
3.4.6.帶複製的基於區域性性最少連結（Locality-Based Least Connections with Replication）
“帶複製的基於區域性性最少連結”排程演算法也是針對目標IP地址的負載均衡，目前主要用於Cache叢集系統。它與LBLC演算法的不同之處是它要維護從一個目標IP地址到一組伺服器的對映，而LBLC演算法維護從一個目標IP地址到一臺伺服器的對映。該演算法根據請求的目標IP地址找出該目標IP地址對應的伺服器組，按“最小連線”原則從伺服器組中選出一臺伺服器，若伺服器沒有超載，將請求傳送到該伺服器；若伺服器超載，則按“最小連線”原則從這個叢集中選出一臺伺服器，將該伺服器加入到伺服器組中，將請求傳送到該伺服器。同時，當該伺服器組有一段時間沒有被修改，將最忙的伺服器從伺服器組中刪除，以降低複製的程度。
3.4.7.目標地址雜湊（Destination Hashing）
“目標地址雜湊”排程演算法根據請求的目標IP地址，作為雜湊鍵（Hash Key）從靜態分配的雜湊表找出對應的伺服器，若該伺服器是可用的且未超載，將請求傳送到該伺服器，否則返回空。
3.4.8.源地址雜湊（Source Hashing）
“源地址雜湊”排程演算法根據請求的源IP地址，作為雜湊鍵（Hash Key）從靜態分配的雜湊表找出對應的伺服器，若該伺服器是可用的且未超載，將請求傳送到該伺服器，否則返回空。
除具備以上負載均衡演算法外，還可以自定義均衡策略。
3.5場景
一般作為入口負載均衡或內部負載均衡，結合反向代理伺服器使用。相關架構可參考Ngnix場景架構。
4、HaProxy負載均衡
HAProxy也是使用較多的一款負載均衡軟體。HAProxy提供高可用性、負載均衡以及基於TCP和HTTP應用的代理，支援虛擬主機，是免費、快速並且可靠的一種解決方案。特別適用於那些負載特大的web站點。執行模式使得它可以很簡單安全的整合到當前的架構中，同時可以保護你的web伺服器不被暴露到網路上。
4.1.特點
- 支援兩種代理模式：TCP（四層）和HTTP（七層），支援虛擬主機；
- 配置簡單，支援url檢測後端伺服器狀態；
- 做負載均衡軟體使用，在高併發情況下，處理速度高於nginx；
- TCP層多用於Mysql從（讀）伺服器負載均衡。 （對Mysql進行負載均衡，對後端的DB節點進行檢測和負載均衡）
- 能夠補充Nginx的一些缺點比如Session的保持，Cookie引導等工作
4.2.均衡策略
支援四種常用演算法：
1.roundrobin：輪詢，輪流分配到後端伺服器；
2.static-rr：根據後端伺服器效能分配；
3.leastconn：最小連線者優先處理；
4.source：根據請求源IP，與Nginx的IP_Hash類似。
五、本次分享總結
以上是本週的分享，從主要講解了軟體負載均衡的應用背景，Ngnix負載均衡，LVS負載均衡，Haproxy負載均衡。
因為時間關係，有些講解的不細緻，大家可以問下度娘/Google，希望本次分享對大家有幫助。
參考資料：
- Nginx負載均衡實現原理圖解 http://www.server110.com/nginx/201403/7225.html
- Nginx架構及其web服務搭建優化配置詳解
- http://linux.it.net.cn/e/server/nginx/2015/0102/11183.html
- Ngnix雙主場景：http://network.51cto.com/art/201109/288597.htm
- 用LVS構架負載均衡Linux叢集系統 linux lvs
- http://blog.chinaunix.net/uid-45094-id-3012037.html
- LVS基本介紹
- http://os.51cto.com/art/201202/317108.htm