http://www.php100.com/html/program/nginx/2013/0905/5525.html
負載均衡是我們大流量網站要做的一個東西，下面我來給大家介紹在Nginx服務器上進行負載均衡配置方法，希望對有需要的同學有所幫助哦。
負載均衡
先來簡單了解一下什么是負載均衡，單從字面上的意思來理解就可以解釋N台服務器平均分擔負載，不會因為某台服務器負載高宕機而某台服務器閑置的情況。那么負載均衡的前提就是要有多台服務器才能實現，也就是兩台以上即可。
測試環境
由於沒有服務器，所以本次測試直接host指定域名，然后在VMware里安裝了三台CentOS。
測試域名 ：a.com
A服務器IP ：192.168.5.149 （主）
B服務器IP ：192.168.5.27
C服務器IP ：192.168.5.126
部署思路
A服務器做為主服務器，域名直接解析到A服務器（192.168.5.149）上，由A服務器負載均衡到B服務器（192.168.5.27）與C服務器（192.168.5.126）上。
域名解析
由於不是真實環境，域名就隨便使用一個a.com用作測試，所以a.com的解析只能在hosts文件設置。
打開：C:WindowsSystem32driversetchosts
在末尾添加
192.168.5.149 a.com
保存退出，然后啟動命令模式ping下看看是否已設置成功
從截圖上看已成功將a.com解析到192.168.5.149IP
A服務器nginx.conf設置
打開nginx.conf，文件位置在nginx安裝目錄的conf目錄下。
在http段加入以下代碼
upstream a.com {
server 192.168.5.126:80;
server 192.168.5.27:80;
}
server{
listen 80;
server_name a.com;
location / {
proxy_pass http://a.com;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
保存重啟nginx
B、C服務器nginx.conf設置
打開nginx.confi，在http段加入以下代碼
server{
listen 80;
server_name a.com;
index index.html;
root /data0/htdocs/www;
}
保存重啟nginx
測試
當訪問a.com的時候，為了區分是轉向哪台服務器處理我分別在B、C服務器下寫一個不同內容的index.html文件，以作區分。
打開瀏覽器訪問a.com結果，刷新會發現所有的請求均分別被主服務器（192.168.5.149）分配到B服務器（192.168.5.27）與C服務器（192.168.5.126）上，實現了負載均衡效果。
B服務器處理頁面
C服務器處理頁面
假如其中一台服務器宕機會怎樣？
當某台服務器宕機了，是否會影響訪問呢？
我們先來看看實例，根據以上例子，假設C服務器192.168.5.126這台機子宕機了（由於無法模擬宕機，所以我就把C服務器關機）然后再來訪問看看。
訪問結果：
我們發現，雖然C服務器（192.168.5.126）宕機了，但不影響網站訪問。這樣，就不會擔心在負載均衡模式下因為某台機子宕機而拖累整個站點了。
如果b.com也要設置負載均衡怎么辦？
很簡單，跟a.com設置一樣。如下：
假設b.com的主服務器IP是192.168.5.149，負載均衡到192.168.5.150和192.168.5.151機器上
現將域名b.com解析到192.168.5.149IP上。
在主服務器(192.168.5.149)的nginx.conf加入以下代碼：
upstream b.com {
server 192.168.5.150:80;
server 192.168.5.151:80;
}
server{
listen 80;
server_name b.com;
location / {
proxy_pass http://b.com;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
保存重啟nginx
在192.168.5.150與192.168.5.151機器上設置nginx，打開nginx.conf在末尾添加以下代碼：
server{
listen 80;
server_name b.com;
index index.html;
root /data0/htdocs/www;
}
保存重啟nginx
完成以后步驟后即可實現b.com的負載均衡配置。
主服務器不能提供服務嗎？
以上例子中，我們都是應用到了主服務器負載均衡到其它服務器上，那么主服務器本身能不能也加在服務器列表中，這樣就不會白白浪費拿一台服務器純當做轉發功能，而是也參與到提供服務中來。
如以上案例三台服務器：
A服務器IP ：192.168.5.149 （主）
B服務器IP ：192.168.5.27
C服務器IP ：192.168.5.126
我們把域名解析到A服務器，然后由A服務器轉發到B服務器與C服務器，那么A服務器只做一個轉發功能，現在我們讓A服務器也提供站點服務。
我們先來分析一下，如果添加主服務器到upstream中，那么可能會有以下兩種情況發生：
1、主服務器轉發到了其它IP上，其它IP服務器正常處理；
2、主服務器轉發到了自己IP上，然后又進到主服務器分配IP那里，假如一直分配到本機，則會造成一個死循環。
怎么解決這個問題呢？因為80端口已經用來監聽負載均衡的處理，那么本服務器上就不能再使用80端口來處理a.com的訪問請求，得用一個新的。於是我們把主服務器的nginx.conf加入以下一段代碼：
server{
listen 8080;
server_name a.com;
index index.html;
root /data0/htdocs/www;
}
重啟nginx，在瀏覽器輸入a.com:8080試試看能不能訪問。結果可以正常訪問
既然能正常訪問，那么我們就可以把主服務器添加到upstream中，但是端口要改一下，如下代碼：
upstream a.com {
server 192.168.5.126:80;
server 192.168.5.27:80;
server 127.0.0.1:8080;
}
由於這里可以添加主服務器IP192.168.5.149或者127.0.0.1均可以，都表示訪問自己。
重啟Nginx，然后再來訪問a.com看看會不會分配到主服務器上。
主服務器也能正常加入服務了。
最后
一、負載均衡不是nginx獨有，著名鼎鼎的apache也有，但性能可能不如nginx。
二、多台服務器提供服務，但域名只解析到主服務器，而真正的服務器IP不會被ping下即可獲得，增加一定安全性。
三、upstream里的IP不一定是內網，外網IP也可以。不過經典的案例是，局域網中某台IP暴露在外網下，域名直接解析到此IP。然后又這台主服務器轉發到內網服務器IP中。
四、某台服務器宕機、不會影響網站正常運行，Nginx不會把請求轉發到已宕機的IP上
解析nginx負載均衡原理
http://baidutech.blog.51cto.com/4114344/1033718/
摘要：對於一個大型網站來說，負載均衡是永恆的話題。隨着硬件技術的迅猛發展，越來越多的負載均衡硬件設備涌現出來，如F5 BIG-IP、Citrix NetScaler、Radware等等，雖然可以解決問題，但其高昂的價格卻往往令人望而卻步，因此負載均衡軟件仍然是大部分公司的不二之選。nginx作為webserver的后起之秀，其優秀的反向代理功能和靈活的負載均衡策略受到了業界廣泛的關注。本文將以工業生產為背景，從設計實現和具體應用等方面詳細介紹nginx負載均衡策略。
關鍵字：nginx 負載均衡 反向代理
1.前言
隨着互聯網信息的爆炸性增長，負載均衡（load balance）已經不再是一個很陌生的話題，顧名思義，負載均衡即是將負載分攤到不同的服務單元，既保證服務的可用性，又保證響應足夠快，給用戶很好的體驗。快速增長的訪問量和數據流量催生了各式各樣的負載均衡產品，很多專業的負載均衡硬件提供了很好的功能，但卻價格不菲，這使得負載均衡軟件大受歡迎，nginx就是其中的一個。
nginx第一個公開版本發布於2004年，2011年發布了1.0版本。它的特點是穩定性高、功能強大、資源消耗低，從其目前的市場占有而言，nginx大有與apache搶市場的勢頭。其中不得不提到的一個特性就是其負載均衡功能，這也成了很多公司選擇它的主要原因。本文將從源碼的角度介紹nginx的內置負載均衡策略和擴展負載均衡策略，以實際的工業生產為案例，對比各負載均衡策略，為nginx使用者提供參考。
2. 源碼剖析
nginx的負載均衡策略可以划分為兩大類：內置策略和擴展策略。內置策略包含加權輪詢和ip hash，在默認情況下這兩種策略會編譯進nginx內核，只需在nginx配置中指明參數即可。擴展策略有很多，如fair、通用hash、consistent hash等，默認不編譯進nginx內核。由於在nginx版本升級中負載均衡的代碼沒有本質性的變化，因此下面將以nginx1.0.15穩定版為例，從源碼角度分析各個策略。
2.1. 加權輪詢（weighted round robin）
輪詢的原理很簡單，首先我們介紹一下輪詢的基本流程。如下是處理一次請求的流程圖：
圖中有兩點需要注意，第一，如果可以把加權輪詢算法分為先深搜索和先廣搜索，那么nginx采用的是先深搜索算法，即將首先將請求都分給高權重的機器，直到該機器的權值降到了比其他機器低，才開始將請求分給下一個高權重的機器；第二，當所有后端機器都down掉時，nginx會立即將所有機器的標志位清成初始狀態，以避免造成所有的機器都處在timeout的狀態，從而導致整個前端被夯住。
接下來看下源碼。nginx源碼的目錄結構很清晰，加權輪詢所在路徑為nginx-1.0.15/src/http/ngx_http_upstream_round_robin.[c|h]，在源碼的基礎上，針對重要的、不易理解的地方我加了注釋。首先看下ngx_http_upstream_round_robin.h中的重要聲明：
從變量命名中，我們就可以大致猜出其作用。其中，current_weight和weight的區別主要是前者為權重排序的值，隨着處理請求會動態的變化，后者是配置值，用於恢復初始狀態。
接下來看下輪詢的創建過程，代碼如下圖所示。
這里有個tried變量需要做些說明。tried中記錄了服務器當前是否被嘗試連接過。他是一個位圖。如果服務器數量小於32，則只需在一個int中即可記錄下所有服務器狀態。如果服務器數量大於32，則需在內存池中申請內存來存儲。對該位圖數組的使用可參考如下代碼：
最后是實際的策略代碼，邏輯很簡單，代碼實現也只有30行，直接上代碼。
2.2. ip hash
ip hash是nginx內置的另一個負載均衡的策略，流程和輪詢很類似，只是其中的算法和具體的策略有些變化，如下圖所示：
ip hash算法的核心實現如下圖：
從代碼中可以看出，hash值既與ip有關又與后端機器的數量有關。經過測試，上述算法可以連續產生1045個互異的value，這是該算法的硬限制。對此nginx使用了保護機制，當經過20次hash仍然找不到可用的機器時，算法退化成輪詢。因此，從本質上說，ip hash算法是一種變相的輪詢算法，如果兩個ip的初始hash值恰好相同，那么來自這兩個ip的請求將永遠落在同一台服務器上，這為均衡性埋下了很深的隱患。
2.3. fair
fair策略是擴展策略，默認不被編譯進nginx內核。其原理是根據后端服務器的響應時間判斷負載情況，從中選出負載最輕的機器進行分流。這種策略具有很強的自適應性，但是實際的網絡環境往往不是那么簡單，因此要慎用。
2.4. 通用hash、一致性hash
這兩種也是擴展策略，在具體的實現上有些差別，通用hash比較簡單，可以以nginx內置的變量為key進行hash，一致性hash采用了nginx內置的一致性hash環，可以支持memcache。
3. 對比測試
本測試主要為了對比各個策略的均衡性、一致性、容災性等，從而分析出其中的差異性，並據此給出各自的適用場景。為了能夠全面、客觀的測試nginx的負載均衡策略，我們采用了兩個測試工具、在不同場景下做測試，以此來降低環境對測試結果造成的影響。首先簡單介紹測試工具、測試網絡拓撲和基本的測試流程。
3.1. 測試工具
3.1.1 easyABC
easyABC是公司內部開發的性能測試工具，采用epool模型實現，簡單易上手，可以模擬GET/POST請求，極限情況下可以提供上萬的壓力，在公司內部得到了廣泛的使用。由於被測試對象為反向代理服務器，因此需要在其后端搭建樁服務器，這里用nginx作為樁webserver，提供最基本的靜態文件服務。
3.1.2 polygraph
polygraph是一款免費的性能測試工具，以對緩存服務、代理、交換機等方面的測試見長。它有規范的配置語言PGL（Polygraph Language），為軟件提供了強大的靈活性。其工作原理如下圖所示：
polygraph提供client端和server端，將測試目標nginx放在二者之間，三者之間的網絡交互均走http協議，只需配置ip+port即可。client端可以配置虛擬robot的個數以及每個robot發請求的速率，並向代理服務器發起隨機的靜態文件請求，server端將按照請求的url生成隨機大小的靜態文件做響應。這也是選用這個測試軟件的一個主要原因：可以產生隨機的url作為nginx各種hash策略的key。
另外，polygraph還提供了日志分析工具，功能比較豐富，感興趣的同學可以參考附錄中的相關材料。
3.2. 測試環境
本測試運行在5台物理機上，其中被測對象單獨搭在一台8核機器上，另外四台4核機器分別搭建了easyABC、webserver樁和polygraph，如下圖所示：
3.3. 測試方案
首先介紹下關鍵的測試指標：
均衡性：是否能夠將請求均勻的發送給后端
一致性：同一個key的請求，是否能落到同一台機器
容災性：當部分后端機器掛掉時，是否能夠正常工作
以上述指標為指導，我們針對如下四個測試場景分別用easyABC和polygraph進行測試：
場景1 server_*均正常提供服務；
場景2 server_4掛掉，其他正常；
場景3 server_3、server_4掛掉，其他正常；
場景4 server_*均恢復正常服務。
上述四個場景將按照時間順序進行，每個場景將建立在上一個場景基礎上，被測試對象無需做任何操作，以最大程度模擬實際情況。另外，考慮到測試工具自身的特點，在easyabc上的測試壓力在17000左右，polygraph上的測試壓力在4000左右。以上測試均保證被測試對象可以正常工作，且無任何notice級別以上（alert/error/warn）的日志出現，在每個場景中記錄下server_*的qps用於最后的策略分析。
3.4. 測試結果
表1和圖1是輪詢策略在兩種測試工具下的負載情況。對比在兩種測試工具下的測試結果會發現，結果完全一致，因此可以排除測試工具的影響。從圖表中可以看出，輪詢策略對於均衡性和容災性都可以做到很好的滿足。(點擊圖片查看大圖)
表2和圖2是fair策略在兩種測試工具下的負載情況。fair策略受環境影響非常大，在排除了測試工具的干擾之后，結果仍然有非常大的抖動。從直觀上講，這完全不滿足均衡性。但是從另一個角度出發，恰恰是由於這種自適應性確保了在復雜的網絡環境中能夠物盡所用。因此，在應用到工業生產中之前，需要在具體的環境中做好測試工作。(點擊圖片查看大圖)
以下圖表是各種hash策略，所不同的僅僅是hash key或者是具體的算法實現，因此一起做對比。實際測試中發現，通用hash和一致性hash均存在一個問題：當某台后端的機器掛掉時，原有落到這台機器上的流量會丟失，但是在ip hash中就不存在這樣的問題。正如上文中對ip hash源碼的分析，當ip hash失效時，會退化為輪詢策略，因此不會有丟失流量的情況。從這個層面上說，ip hash也可以看成是輪詢的升級版。(點擊圖片查看大圖)
圖5為ip hash策略，ip hash是nginx內置策略，可以看做是前兩種策略的特例：以來源ip為key。由於測試工具不便於模擬海量ip下的請求，因此這里截取線上實際的情況加以分析，如下圖所示：
圖5 ip hash策略
圖中前1/3使用輪詢策略，中間段使用ip hash策略，后1/3仍然是輪詢策略。可以明顯的看出，ip hash的均衡性存在着很大的問題。原因並不難分析，在實際的網絡環境中，有大量的高校出口路由器ip、企業出口路由器ip等網絡節點，這些節點帶來的流量往往是普通用戶的成百上千倍，而ip hash策略恰恰是按照ip來划分流量，因此造成上述后果也就自然而然了。
4. 總結與展望
通過實際的對比測試，我們對nginx各個負載均衡策略進行了驗證。下面從均衡性、一致性、容災性以及適用場景等角度對比各種策略。(點擊圖片查看大圖)
以上從源碼和實際的測試數據角度分析說明了nginx負載均衡的策略，並給出了各種策略適合的應用場景。通過本文的分析不難發現，無論哪種策略都不是萬金油，在具體的場景下應該選擇哪種策略一定程度上依賴於使用者對這些策略的熟悉程度。希望本文的分析和測試數據能夠對讀者有所幫助，更希望有越來越多、越來越好的負載均衡策略產出。
5. 參考資料
http://wiki.nginx.org/HttpUpstreamConsistentHash
http://wiki.nginx.org/HttpUpstreamFairModule