關(guān)于nginx的安裝和基本配置請參考nginx超营，本文在原基礎(chǔ)上完成以下幾個功能：
結(jié)合proxy和upstream模塊實(shí)現(xiàn)nginx負(fù)載均衡
結(jié)合nginx_upstream_check_module模塊實(shí)現(xiàn)后端服務(wù)器的健康檢查
使用nginx-sticky-module擴(kuò)展模塊實(shí)現(xiàn)Cookie會話黏貼（session-sticky效果）
使用proxy模塊實(shí)現(xiàn)靜態(tài)文件緩存
使用ngx_cache_purge實(shí)現(xiàn)更強(qiáng)大的緩存清除功能
上面提到的3個模塊都屬于第三方擴(kuò)展模塊塑陵，需要提前下好源碼，然后編譯時通過--add-moudle=src_path一起安裝凯傲。
注意：
使用 nginx_upstream_check_module(簡記為m1) 時要先為nginx打上相應(yīng)版本的patch，我的nginx版本為 1.6.3，所以patch對應(yīng) m1 解壓后目錄下的check_1.5.12+.patch侠畔，所以進(jìn)入nginx源碼目錄，執(zhí)行 patch -p1 …（見下方示例）
nginx-sticky-module-ng(簡記為m2) 模塊可以單獨(dú)使用损晤，但是因?yàn)閙1監(jiān)控檢查的方式是依賴于m2的软棺，所以要使用m2，還要對m1打上patch尤勋，進(jìn)入m2源碼目錄喘落，執(zhí)行 patch -p0…
編譯示例：（CentOS 6.5 x86_64, nginx 1.6.3）
# yum -y install gcc gcc-c++ make libtool zlib zlib-devel openssl openssl--devel pcre pcre-devel
# cd nginx-1.6.3
# patch -p1 < ../nginx_upstream_check_module-0.3.0/check_1.5.12+.patch
# cd ../nginx-sticky-module-ng-1.2.5
# patch -p0 < ../nginx_upstream_check_module-0.3.0/nginx-sticky-module.patch
# ./configure --prefix=/usr/local/nginx-1.6 --with-pcre
--with-http_stub_status_module --with-http_ssl_module --with-http_gzip_static_module --with-http_realip_module
--add-module=../nginx_upstream_check_module-0.3.0 --add-module=../nginx-sticky-module-ng-1.2.5 --add-module=../ngx_cache_purge-2.3
# make && make install
如果你想在已安裝好的nginx上添加第三方模塊茵宪，依然需要重新編譯，但為了不覆蓋你原有的配置瘦棋，請不要make install稀火，而是直接拷貝可執(zhí)行文件：
# nginx -V//可以看到原來的編譯選項(xiàng)，下面用到
# ./configure ... --add-module=..//你的第三方模塊
# make//make后不要install兽狭，改用手動拷貝憾股。先備份
# cp objs/nginx /usr/local/nginx-1.6/sbin/nginx
項(xiàng)目地址：https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng
這個模塊的作用是通過cookie黏貼的方式將來自同一個客戶端（瀏覽器）的請求發(fā)送到同一個后端服務(wù)器上處理，這樣一定程度上可以解決多個backend servers的session同步的問題 —— 因?yàn)椴辉傩枰交郏鳵R輪詢模式必須要運(yùn)維人員自己考慮session同步的實(shí)現(xiàn)服球。
另外內(nèi)置的 ip_hash 也可以實(shí)現(xiàn)根據(jù)客戶端IP來分發(fā)請求，但它很容易造成負(fù)載不均衡的情況颠焦，而如果nginx前面有CDN網(wǎng)絡(luò)或者來自同一局域網(wǎng)的訪問斩熊，它接收的客戶端IP是一樣的，容易造成負(fù)載不均衡現(xiàn)象伐庭。淘寶Tengine的 ngx_http_upstream_session_sticky_module 也是類似的功能粉渠。nginx-sticky-module的cookie過期時間，默認(rèn)瀏覽器關(guān)閉就過期圾另，也就是會話方式霸株。
這個模塊并不合適不支持 Cookie 或手動禁用了cookie的瀏覽器，此時默認(rèn)sticky就會切換成RR集乔。它不能與ip_hash同時使用去件。
upstream backend {
server172.29.88.226:8080weight=1;
server172.29.88.227:8080weight=1;
sticky;
}
配置起來超級簡單，一般來說一個sticky指令就夠了扰路。
sticky [name=route] [domain=.foo.bar] [path=/] [expires=1h] [hash=index|md5|sha1] [no_fallback];：
name: 可以為任何的 string 字符,默認(rèn)是 route
domain：哪些域名下可以使用這個 cookie
path：哪些路徑對啟用 sticky尤溜，例如 path/test，那么只有 test 這個目錄才會使用 sticky 做負(fù)載均衡
expires：cookie 過期時間汗唱，默認(rèn)瀏覽器關(guān)閉就過期宫莱，也就是會話方式。
no_fallbackup：如果設(shè)置了這個哩罪，cookie 對應(yīng)的服務(wù)器宕機(jī)了授霸，那么將會返回502（bad gateway 或者 proxy error），建議不啟用
你在查看官方文檔可能會注意到里面也有個 sticky 指令际插，要說它們的作用幾乎是一樣的碘耳，但是你可能注意到This directive is available as part of our commercial subscription.的說明 —— 這是nginx商業(yè)版本里才有的特性。包括后面的check指令腹鹉，在nginx的商業(yè)版本里也有對應(yīng)的health_check（配在 location ）實(shí)現(xiàn)幾乎一樣的監(jiān)控檢查功能。
這里順帶介紹一下nginx的負(fù)載均衡模塊支持的其它調(diào)度算法：
輪詢（默認(rèn)） ： 每個請求按時間順序逐一分配到不同的后端服務(wù)器敷硅，如果后端某臺服務(wù)器宕機(jī)功咒，故障系統(tǒng)被自動剔除愉阎，使用戶訪問不受影響。Weight 指定輪詢權(quán)值力奋，Weight值越大榜旦，分配到的訪問機(jī)率越高，主要用于后端每個服務(wù)器性能不均的情況下景殷。
ip_hash： 每個請求按訪問IP的hash結(jié)果分配溅呢，這樣來自同一個IP的訪客固定訪問一個后端服務(wù)器，有效解決了動態(tài)網(wǎng)頁存在的session共享問題猿挚。當(dāng)然如果這個節(jié)點(diǎn)不可用了咐旧，會發(fā)到下個節(jié)點(diǎn)，而此時沒有session同步的話就注銷掉了绩蜻。
least_conn： 請求被發(fā)送到當(dāng)前活躍連接最少的realserver上铣墨。會考慮weight的值。
url_hash： 此方法按訪問url的hash結(jié)果來分配請求办绝，使每個url定向到同一個后端服務(wù)器伊约，可以進(jìn)一步提高后端緩存服務(wù)器的效率。Nginx本身是不支持url_hash的孕蝉，如果需要使用這種調(diào)度算法屡律，必須安裝Nginx 的hash軟件包 nginx_upstream_hash 。
fair： 這是比上面兩個更加智能的負(fù)載均衡算法降淮。此種算法可以依據(jù)頁面大小和加載時間長短智能地進(jìn)行負(fù)載均衡超埋，也就是根據(jù)后端服務(wù)器的響應(yīng)時間來分配請求，響應(yīng)時間短的優(yōu)先分配骤肛。Nginx本身是不支持fair的纳本，如果需要使用這種調(diào)度算法，必須下載Nginx的 upstream_fair 模塊腋颠。
嚴(yán)格來說繁成，nginx自帶是沒有針對負(fù)載均衡后端節(jié)點(diǎn)的健康檢查的，但是可以通過默認(rèn)自帶的 ngx_http_proxy_module 模塊和 ngx_http_upstream_module 模塊中的相關(guān)指令來完成當(dāng)后端節(jié)點(diǎn)出現(xiàn)故障時淑玫，自動切換到下一個節(jié)點(diǎn)來提供訪問巾腕。
upstream backend {
ip_hash;
server172.29.88.226:8080weight2;
server172.29.88.226:8080weight=1max_fails=2fail_timeout=30s;
server172.29.88.227:8080backup;
}
server {
location / {
proxy_pass http://backend;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503 http_504;
}
weight： 輪詢權(quán)值也是可以用在ip_hash的，默認(rèn)值為1
max_fails： 允許請求失敗的次數(shù)絮蒿，默認(rèn)為1尊搬。當(dāng)超過最大次數(shù)時，返回proxy_next_upstream 模塊定義的錯誤土涝。
fail_timeout： 有兩層含義佛寿，一是在 30s 時間內(nèi)最多容許 2 次失敗；二是在經(jīng)歷了 2 次失敗以后冀泻，30s時間內(nèi)不分配請求到這臺服務(wù)器常侣。
backup： 預(yù)留的備份機(jī)器。當(dāng)其他所有的非backup機(jī)器出現(xiàn)故障的時候弹渔，才會請求backup機(jī)器胳施，因此這臺機(jī)器的壓力最輕。（為什么我的1.6.3版本里配置backup啟動nginx時說invalid parameter "backup"肢专？）
max_conns： 限制同時連接到某臺后端服務(wù)器的連接數(shù)舞肆，默認(rèn)為0即無限制。因?yàn)閝ueue指令是commercial博杖，所以還是保持默認(rèn)吧椿胯。
proxy_next_upstream： 這個指令屬于 http_proxy 模塊的，指定后端返回什么樣的異常響應(yīng)時欧募，使用另一個realserver
3.2 nginx_upstream_check_module
nginx_upstream_check_module 是專門提供負(fù)載均衡器內(nèi)節(jié)點(diǎn)的健康檢查的外部模塊压状，由淘寶的姚偉斌大神開發(fā)，通過它可以用來檢測后端 realserver 的健康狀態(tài)跟继。如果后端 realserver 不可用种冬，則后面的請求就不會轉(zhuǎn)發(fā)到該節(jié)點(diǎn)上，并持續(xù)檢查幾點(diǎn)的狀態(tài)舔糖。在淘寶自己的 tengine 上是自帶了該模塊娱两。項(xiàng)目地址：https://github.com/yaoweibin/nginx_upstream_check_module。
下面的是一個帶后端監(jiān)控檢查的 nginx.conf 配置：
upstream backend {
sticky;? ? # or simple round-robin
server172.29.88.226:8080weight=2;
server172.29.88.226:8081weight=1max_fails=2fail_timeout=30s;
server172.29.88.227:8080weight=1max_fails=2fail_timeout=30s;
server172.29.88.227:8081;
check interval=5000rise=2fall=3timeout=1000type=http;
check_http_send "HEAD / HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}
server {
location / {
proxy_pass http://backend;
}
location /status {
check_status;
access_log? off;
allow172.29.73.23;
deny all;
}
上面配置的意思是金吗，對name這個負(fù)載均衡條目中的所有節(jié)點(diǎn)十兢，每個5秒檢測一次，請求2次正常則標(biāo)記 realserver狀態(tài)為up摇庙，如果檢測 3 次都失敗旱物，則標(biāo)記 realserver的狀態(tài)為down，超時時間為1秒卫袒。
check指令只能出現(xiàn)在upstream中：
interval： 向后端發(fā)送的健康檢查包的間隔宵呛。
fall： 如果連續(xù)失敗次數(shù)達(dá)到fall_count，服務(wù)器就被認(rèn)為是down夕凝。
rise： 如果連續(xù)成功次數(shù)達(dá)到rise_count宝穗，服務(wù)器就被認(rèn)為是up。
timeout： 后端健康請求的超時時間码秉。
default_down： 設(shè)定初始時服務(wù)器的狀態(tài)逮矛，如果是true，就說明默認(rèn)是down的转砖，如果是false须鼎，就是up的。默認(rèn)值是true，也就是一開始服務(wù)器認(rèn)為是不可用晋控，要等健康檢查包達(dá)到一定成功次數(shù)以后才會被認(rèn)為是健康的挑围。
type：健康檢查包的類型，現(xiàn)在支持以下多種類型
tcp：簡單的tcp連接糖荒，如果連接成功，就說明后端正常模捂。
http：發(fā)送HTTP請求捶朵，通過后端的回復(fù)包的狀態(tài)來判斷后端是否存活。
ajp：向后端發(fā)送AJP協(xié)議的Cping包狂男，通過接收Cpong包來判斷后端是否存活综看。
ssl_hello：發(fā)送一個初始的SSL hello包并接受服務(wù)器的SSL hello包。
mysql: 向mysql服務(wù)器連接岖食，通過接收服務(wù)器的greeting包來判斷后端是否存活红碑。
fastcgi：發(fā)送一個fastcgi請求，通過接受解析fastcgi響應(yīng)來判斷后端是否存活
port: 指定后端服務(wù)器的檢查端口泡垃。你可以指定不同于真實(shí)服務(wù)的后端服務(wù)器的端口析珊，比如后端提供的是443端口的應(yīng)用，你可以去檢查80端口的狀態(tài)來判斷后端健康狀況蔑穴。默認(rèn)是0忠寻，表示跟后端server提供真實(shí)服務(wù)的端口一樣。該選項(xiàng)出現(xiàn)于Tengine-1.4.0存和。
如果 type 為 http 奕剃，你還可以使用check_http_send來配置http監(jiān)控檢查包發(fā)送的請求內(nèi)容，為了減少傳輸數(shù)據(jù)量捐腿，推薦采用 HEAD 方法纵朋。當(dāng)采用長連接進(jìn)行健康檢查時，需在該指令中添加keep-alive請求頭茄袖，如：HEAD / HTTP/1.1\r\nConnection: keep-alive\r\n\r\n操软。當(dāng)采用 GET 方法的情況下，請求uri的size不宜過大绞佩，確彼屡福可以在1個interval內(nèi)傳輸完成，否則會被健康檢查模塊視為后端服務(wù)器或網(wǎng)絡(luò)異常品山。
check_http_expect_alive指定HTTP回復(fù)的成功狀態(tài)胆建，默認(rèn)認(rèn)為 2XX 和 3XX 的狀態(tài)是健康的。
nginx的頁面緩存功能與上面的負(fù)載均衡和健康檢查是沒有關(guān)系的肘交，放在這里一是因?yàn)閼械迷倨鹨黄恼掳试兀窃儆衛(wèi)oad-balance的地方一般都會啟用緩存的。
緩存也就是將js、css凉驻、image等靜態(tài)文件從tomcat緩存到nginx指定的緩存目錄下腻要，既可以減輕tomcat負(fù)擔(dān)，也可以加快訪問速度涝登，但這樣緩存及時清理成為了一個問題雄家，所以需要ngx_cache_purge這個模塊來在過期時間未到之前，手動清理緩存胀滚。（這里有篇文章趟济，對比使用緩存、不使用緩存咽笼、使用動靜分離三種情況下顷编，高并發(fā)性能比較。使用代理緩存功能性能會高出很多倍）
http {
... // $upstream_cache_status記錄緩存命中率
log_format? main'$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"'
'"$upstream_cache_status"';
proxy_temp_path? /usr/local/nginx-1.6/proxy_temp;
proxy_cache_path /usr/local/nginx-1.6/proxy_cache levels=1:2keys_zone=cache_one:100m inactive=2d max_size=2g;
server {
listen80;
server_name? ittest.example.com;
root? html;
index? index.html index.htm index.jsp;
location ~ .*\.(gif|jpg|png|html|css|js|ico|swf|pdf)(.*) {
proxy_pass? http://backend;
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header? X-Real-IP? $remote_addr;
proxy_set_header? X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_cache cache_one;
add_header Nginx-Cache $upstream_cache_status;
proxy_cache_valid2003043013028h;
proxy_cache_valid4041m;
proxy_cache_valid? any2d;
proxy_cache_key $host$uri$is_args$args;
expires30d;
}
location ~ /purge(/.*) {
#設(shè)置只允許指定的IP或IP段才可以清除URL緩存剑刑。
allow127.0.0.1;
allow172.29.73.0/24;
deny? ? all;
proxy_cache_purge? cache_one $host$1$is_args$args;
error_page405=200/purge$1;
}
}
}
說明
proxy_temp_path： 緩存臨時目錄媳纬。后端的響應(yīng)并不直接返回客戶端，而是先寫到一個臨時文件中施掏，然后被rename一下當(dāng)做緩存放在 proxy_cache_path 钮惠。0.8.9版本以后允許temp和cache兩個目錄在不同文件系統(tǒng)上（分區(qū)），然而為了減少性能損失還是建議把它們設(shè)成一個文件系統(tǒng)上七芭。
proxy_cache_path ...： 設(shè)置緩存目錄萌腿，目錄里的文件名是 cache_key 的MD5值。
levels=1:2 keys_zone=cache_one:50m表示采用2級目錄結(jié)構(gòu)抖苦，Web緩存區(qū)名稱為cache_one毁菱，內(nèi)存緩存空間大小為100MB，這個緩沖zone可以被多次使用锌历。文件系統(tǒng)上看到的緩存文件名類似于 /usr/local/nginx-1.6/proxy_cache/c/29/b7f54b2df7773722d382f4809d65029c贮庞。
inactive=2d max_size=2g表示2天沒有被訪問的內(nèi)容自動清除，硬盤最大緩存空間為2GB究西，超過這個大學(xué)將清除最近最少使用的數(shù)據(jù)窗慎。
proxy_cache： 引用前面定義的緩存區(qū) cache_one
proxy_cache_key： 定義cache_key
proxy_cache_valid： 為不同的響應(yīng)狀態(tài)碼設(shè)置不同的緩存時間，比如200卤材、302等正常結(jié)果可以緩存的時間長點(diǎn)遮斥，而404、500等緩存時間設(shè)置短一些扇丛，這個時間到了文件就會過期术吗，而不論是否剛被訪問過。
expires： 在響應(yīng)頭里設(shè)置Expires:或Cache-Control:max-age帆精，返回給客戶端的瀏覽器緩存失效時間较屿。
關(guān)于緩存的失效期限上面有三個選項(xiàng)：X-Accel-Expires隧魄、inactive、proxy_cache_valid隘蝎、expires购啄，它們之間是有優(yōu)先級的，按上面的順序如果在header里設(shè)置 X-Accel-Expires 則它的優(yōu)先級最高嘱么，否則inactive優(yōu)先級最高狮含。更多資料請參考nginx緩存優(yōu)先級或這里。
上述配置的proxy_cache_purge指令用于方便的清除緩存曼振，但必須按照第三方的 ngx_cache_purge 模塊才能使用辉川，項(xiàng)目地址：https://github.com/FRiCKLE/ngx_cache_purge/。
使用 ngx_cache_purge 模塊清除緩存有2種辦法（直接刪除緩存目錄下的文件也算一種辦法）：
echo發(fā)送PURGE指令
proxy_cache_purge PURGE from 127.0.0.1表示只允許在來自本地的清除指令
1
# echo -e'PURGE / HTTP/1.0\r\n'| nc 127.0.0.1 80
GET方式請求URL
即使用配置文件中的location ~ /purge(/.*)拴测，瀏覽器訪問http://ittest.example.com/purge/your/may/path來清除緩存，或者echo -e 'GET /purge/ HTTP/1.0\r\n' | nc ittest.example.com 80
參考
Nginx實(shí)戰(zhàn)系列之功能篇—-后端節(jié)點(diǎn)健康檢查
Tengine nginx_upstream_check_module
