關于nginx的安裝和基本配置請參考nginx，本文在原基礎上完成以下幾個功能：
結合proxy和upstream模塊實現nginx負載均衡
結合nginx_upstream_check_module模塊實現后端服務器的健康檢查
使用nginx-sticky-module擴展模塊實現Cookie會話黏貼（session-sticky效果）
使用proxy模塊實現靜態文件緩存
使用ngx_cache_purge實現更強大的緩存清除功能
上面提到的3個模塊都屬于第三方擴展模塊，需要提前下好源碼，然后編譯時通過--add-moudle=src_path一起安裝。
注意：
使用 nginx_upstream_check_module(簡記為m1) 時要先為nginx打上相應版本的patch，我的nginx版本為 1.6.3，所以patch對應 m1 解壓后目錄下的check_1.5.12+.patch，所以進入nginx源碼目錄，執行 patch -p1 …（見下方示例）
nginx-sticky-module-ng(簡記為m2) 模塊可以單獨使用，但是因為m1監控檢查的方式是依賴于m2的，所以要使用m2，還要對m1打上patch，進入m2源碼目錄，執行 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，而是直接拷貝可執行文件：
# nginx -V//可以看到原來的編譯選項，下面用到
# ./configure ... --add-module=..//你的第三方模塊
# make//make后不要install，改用手動拷貝。先備份
# cp objs/nginx /usr/local/nginx-1.6/sbin/nginx
項目地址：https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng
這個模塊的作用是通過cookie黏貼的方式將來自同一個客戶端（瀏覽器）的請求發送到同一個后端服務器上處理，這樣一定程度上可以解決多個backend servers的session同步的問題 —— 因為不再需要同步，而RR輪詢模式必須要運維人員自己考慮session同步的實現。
另外內置的 ip_hash 也可以實現根據客戶端IP來分發請求，但它很容易造成負載不均衡的情況，而如果nginx前面有CDN網絡或者來自同一局域網的訪問，它接收的客戶端IP是一樣的，容易造成負載不均衡現象。淘寶Tengine的 ngx_http_upstream_session_sticky_module 也是類似的功能。nginx-sticky-module的cookie過期時間，默認瀏覽器關閉就過期，也就是會話方式。
這個模塊并不合適不支持 Cookie 或手動禁用了cookie的瀏覽器，此時默認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 字符,默認是 route
domain：哪些域名下可以使用這個 cookie
path：哪些路徑對啟用 sticky，例如 path/test，那么只有 test 這個目錄才會使用 sticky 做負載均衡
expires：cookie 過期時間，默認瀏覽器關閉就過期，也就是會話方式。
no_fallbackup：如果設置了這個，cookie 對應的服務器宕機了，那么將會返回502（bad gateway 或者 proxy error），建議不啟用
你在查看官方文檔可能會注意到里面也有個 sticky 指令，要說它們的作用幾乎是一樣的，但是你可能注意到This directive is available as part of our commercial subscription.的說明 —— 這是nginx商業版本里才有的特性。包括后面的check指令，在nginx的商業版本里也有對應的health_check（配在 location ）實現幾乎一樣的監控檢查功能。
這里順帶介紹一下nginx的負載均衡模塊支持的其它調度算法：
輪詢（默認） ： 每個請求按時間順序逐一分配到不同的后端服務器，如果后端某臺服務器宕機，故障系統被自動剔除，使用戶訪問不受影響。Weight 指定輪詢權值，Weight值越大，分配到的訪問機率越高，主要用于后端每個服務器性能不均的情況下。
ip_hash： 每個請求按訪問IP的hash結果分配，這樣來自同一個IP的訪客固定訪問一個后端服務器，有效解決了動態網頁存在的session共享問題。當然如果這個節點不可用了，會發到下個節點，而此時沒有session同步的話就注銷掉了。
least_conn： 請求被發送到當前活躍連接最少的realserver上。會考慮weight的值。
url_hash： 此方法按訪問url的hash結果來分配請求，使每個url定向到同一個后端服務器，可以進一步提高后端緩存服務器的效率。Nginx本身是不支持url_hash的，如果需要使用這種調度算法，必須安裝Nginx 的hash軟件包 nginx_upstream_hash 。
fair： 這是比上面兩個更加智能的負載均衡算法。此種算法可以依據頁面大小和加載時間長短智能地進行負載均衡，也就是根據后端服務器的響應時間來分配請求，響應時間短的優先分配。Nginx本身是不支持fair的，如果需要使用這種調度算法，必須下載Nginx的 upstream_fair 模塊。
嚴格來說，nginx自帶是沒有針對負載均衡后端節點的健康檢查的，但是可以通過默認自帶的 ngx_http_proxy_module 模塊和 ngx_http_upstream_module 模塊中的相關指令來完成當后端節點出現故障時，自動切換到下一個節點來提供訪問。
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： 輪詢權值也是可以用在ip_hash的，默認值為1
max_fails： 允許請求失敗的次數，默認為1。當超過最大次數時，返回proxy_next_upstream 模塊定義的錯誤。
fail_timeout： 有兩層含義，一是在 30s 時間內最多容許 2 次失敗；二是在經歷了 2 次失敗以后，30s時間內不分配請求到這臺服務器。
backup： 預留的備份機器。當其他所有的非backup機器出現故障的時候，才會請求backup機器，因此這臺機器的壓力最輕。（為什么我的1.6.3版本里配置backup啟動nginx時說invalid parameter "backup"？）
max_conns： 限制同時連接到某臺后端服務器的連接數，默認為0即無限制。因為queue指令是commercial，所以還是保持默認吧。
proxy_next_upstream： 這個指令屬于 http_proxy 模塊的，指定后端返回什么樣的異常響應時，使用另一個realserver
3.2 nginx_upstream_check_module
nginx_upstream_check_module 是專門提供負載均衡器內節點的健康檢查的外部模塊，由淘寶的姚偉斌大神開發，通過它可以用來檢測后端 realserver 的健康狀態。如果后端 realserver 不可用，則后面的請求就不會轉發到該節點上，并持續檢查幾點的狀態。在淘寶自己的 tengine 上是自帶了該模塊。項目地址：https://github.com/yaoweibin/nginx_upstream_check_module。
下面的是一個帶后端監控檢查的 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這個負載均衡條目中的所有節點，每個5秒檢測一次，請求2次正常則標記 realserver狀態為up，如果檢測 3 次都失敗，則標記 realserver的狀態為down，超時時間為1秒。
check指令只能出現在upstream中：
interval： 向后端發送的健康檢查包的間隔。
fall： 如果連續失敗次數達到fall_count，服務器就被認為是down。
rise： 如果連續成功次數達到rise_count，服務器就被認為是up。
timeout： 后端健康請求的超時時間。
default_down： 設定初始時服務器的狀態，如果是true，就說明默認是down的，如果是false，就是up的。默認值是true，也就是一開始服務器認為是不可用，要等健康檢查包達到一定成功次數以后才會被認為是健康的。
type：健康檢查包的類型，現在支持以下多種類型
tcp：簡單的tcp連接，如果連接成功，就說明后端正常。
http：發送HTTP請求，通過后端的回復包的狀態來判斷后端是否存活。
ajp：向后端發送AJP協議的Cping包，通過接收Cpong包來判斷后端是否存活。
ssl_hello：發送一個初始的SSL hello包并接受服務器的SSL hello包。
mysql: 向mysql服務器連接，通過接收服務器的greeting包來判斷后端是否存活。
fastcgi：發送一個fastcgi請求，通過接受解析fastcgi響應來判斷后端是否存活
port: 指定后端服務器的檢查端口。你可以指定不同于真實服務的后端服務器的端口，比如后端提供的是443端口的應用，你可以去檢查80端口的狀態來判斷后端健康狀況。默認是0，表示跟后端server提供真實服務的端口一樣。該選項出現于Tengine-1.4.0。
如果 type 為 http ，你還可以使用check_http_send來配置http監控檢查包發送的請求內容，為了減少傳輸數據量，推薦采用 HEAD 方法。當采用長連接進行健康檢查時，需在該指令中添加keep-alive請求頭，如：HEAD / HTTP/1.1\r\nConnection: keep-alive\r\n\r\n。當采用 GET 方法的情況下，請求uri的size不宜過大，確保可以在1個interval內傳輸完成，否則會被健康檢查模塊視為后端服務器或網絡異常。
check_http_expect_alive指定HTTP回復的成功狀態，默認認為 2XX 和 3XX 的狀態是健康的。
nginx的頁面緩存功能與上面的負載均衡和健康檢查是沒有關系的，放在這里一是因為懶得再起一篇文章，二是再有load-balance的地方一般都會啟用緩存的。
緩存也就是將js、css、image等靜態文件從tomcat緩存到nginx指定的緩存目錄下，既可以減輕tomcat負擔，也可以加快訪問速度，但這樣緩存及時清理成為了一個問題，所以需要ngx_cache_purge這個模塊來在過期時間未到之前，手動清理緩存。（這里有篇文章，對比使用緩存、不使用緩存、使用動靜分離三種情況下，高并發性能比較。使用代理緩存功能性能會高出很多倍）
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(/.*) {
#設置只允許指定的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： 緩存臨時目錄。后端的響應并不直接返回客戶端，而是先寫到一個臨時文件中，然后被rename一下當做緩存放在 proxy_cache_path 。0.8.9版本以后允許temp和cache兩個目錄在不同文件系統上（分區），然而為了減少性能損失還是建議把它們設成一個文件系統上。
proxy_cache_path ...： 設置緩存目錄，目錄里的文件名是 cache_key 的MD5值。
levels=1:2 keys_zone=cache_one:50m表示采用2級目錄結構，Web緩存區名稱為cache_one，內存緩存空間大小為100MB，這個緩沖zone可以被多次使用。文件系統上看到的緩存文件名類似于 /usr/local/nginx-1.6/proxy_cache/c/29/b7f54b2df7773722d382f4809d65029c。
inactive=2d max_size=2g表示2天沒有被訪問的內容自動清除，硬盤最大緩存空間為2GB，超過這個大學將清除最近最少使用的數據。
proxy_cache： 引用前面定義的緩存區 cache_one
proxy_cache_key： 定義cache_key
proxy_cache_valid： 為不同的響應狀態碼設置不同的緩存時間，比如200、302等正常結果可以緩存的時間長點，而404、500等緩存時間設置短一些，這個時間到了文件就會過期，而不論是否剛被訪問過。
expires： 在響應頭里設置Expires:或Cache-Control:max-age，返回給客戶端的瀏覽器緩存失效時間。
關于緩存的失效期限上面有三個選項：X-Accel-Expires、inactive、proxy_cache_valid、expires，它們之間是有優先級的，按上面的順序如果在header里設置 X-Accel-Expires 則它的優先級最高，否則inactive優先級最高。更多資料請參考nginx緩存優先級或這里。
上述配置的proxy_cache_purge指令用于方便的清除緩存，但必須按照第三方的 ngx_cache_purge 模塊才能使用，項目地址：https://github.com/FRiCKLE/ngx_cache_purge/。
使用 ngx_cache_purge 模塊清除緩存有2種辦法（直接刪除緩存目錄下的文件也算一種辦法）：
echo發送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
參考
