硬體負載均衡效能優越，功能全面，但是**昂貴，一般適合初期或者土豪級公司長期使用。因此軟體負載均衡在網際網路領域大量使用。常用的軟體負載均衡軟體有nginx，lvs，haproxy等。本文參考大量文件，部分為直接拷貝，參考出處見負載均衡詳解（4）。
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萬併發的。具體效能看應用場景。
1.模組化設計：良好的擴充套件性，可以通過模組方式進行功能擴充套件。
2.高可靠性：主控程序和worker是同步實現的，乙個worker出現問題，會立刻啟動另乙個worker。
3.記憶體消耗低：一萬個長連線（keep-alive）,僅消耗2.5mb記憶體。
4.支援熱部署：不用停止伺服器，實現更新配置檔案，更換日誌檔案、更新伺服器程式版本。
5.併發能力強：官方資料每秒支援5萬併發；
6.功能豐富：優秀的反向**功能和靈活的負載均衡策略
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.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復用機制）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內建的另乙個負載均衡的策略，流程和輪詢很類似，只是其中的演算法和具體的策略有些變化，如下圖所示：
fair策略是擴充套件策略，預設不被編譯進nginx核心。其原理是根據後端伺服器的響應時間判斷負載情況，從中選出負載最輕的機器進行分流。這種策略具有很強的自適應性，但是實際的網路環境往往不是那麼簡單，因此要慎用。
2.4.4 通用hash、一致性hash
這兩種也是擴充套件策略，在具體的實現上有些差別，通用hash比較簡單，可以以nginx內建的變數為key進行hash，一致性hash採用了nginx內建的一致性hash環，可以支援memcache。
ngnix一般作為入口負載均衡或內部負載均衡，結合反向**伺服器使用。以下架構示例，僅供參考，具體使用根據場景而定。
2.5.1入口負載均衡架構
！ngnix伺服器在使用者訪問的最前端。根據使用者請求再**到具體的應用伺服器或二級負載均衡伺服器（lvs）
2.5.2內部負載均衡架構
lvs作為入口負載均衡，將請求**到二級ngnix伺服器，ngnix再根據請求**到具體的應用伺服器。
2.5.3ngnix高可用
分布式系統中，應用只部署一台伺服器會存在單點故障，負載均衡同樣有類似的問題。一般可採用主備或負載均衡裝置集群的方式節約單點故障或高併發請求分流。
ngnix高可用，至少包含兩個ngnix伺服器，一台主伺服器，一台備伺服器，之間使用keepalived做健康監控和故障檢測。開放vip埠，通過防火牆進行外部對映。
dns解析公網的ip實際為vip。
CDN內容負載均衡軟體介紹
隨著網際網路的發展，使用者在使用網路時對 的瀏覽速度和效果愈加重視，但由於網民數量激增，網路訪問路徑過長，從而使使用者的訪問質量受到嚴重影響。特別是當使用者與 之間的鏈路被突發的大流量資料擁塞時，對於異地網際網路使用者急速增加的地區來說，訪問質量不良更是乙個急待解決的問題。如何才能讓各地的使用者都能...
Linux負載均衡軟體LVS簡介
linux負載均衡軟體lvs lvs集群的體系結構以及特點 1 lvs簡介2 lvs體系結構 使用lvs架設的伺服器集群系統有三個部分組成 最前端的負載均衡層，用load balancer表示，中間的伺服器群組層，用server array表示，最底端的資料共享儲存層，用shared storage...
nginx 負載均衡 Nginx負載均衡策略
nginx提供的負載均衡策略有2種 內建策略和擴充套件策略。內建策略為輪詢 預設 加權輪詢，ip hash，第三方。upstream mysvr1 輪詢 每個請求按照時間順序逐一的分配到每乙個後台伺服器上。如果某台伺服器宕機了，將會自動的剔除宕機的服務。nginx預設就是輪詢其權重都預設為1，伺服器...