upstream backend {
ip_hash;
server 192.168.1.225:8080 weight 2;
server 192.168.1.226:8080 weight=1 max_fails=2 fail_timeout=30s ;
server 192.168.1.227:8080 backup;
}
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機器 max_conns： 限制同時連接到某台後端服務器的連接數，默認為0即無限制。因為queue指令是commercial，所以還是保持默認吧。 proxy_next_upstream：這個指令屬於 http_proxy 模塊的，指定後端返回什麼樣的異常響應時，使用另一個realserver 項目地址： https://bitbucket.org/nginx-goodies/nginx-sticky-module-ng https://code.google.com/p/nginx-sticky-module/ 3、 upstream_check nginx自帶是沒有針對負載均衡後端節點的健康檢查的，但是可以通過默認自帶的 ngx_http_proxy_module 模塊和 ngx_http_upstream_module 模塊中的相關指令來完成當後端節點出現故障時，自動切換到下一個節點來提供訪問。 nginx_upstream_check_module 是專門提供負載均衡器內節點的健康檢查的外部模塊，由淘寶工程師開發，通過它可以用來檢測後端 realserver 的健康狀態。如果後端 realserver 不可用，則後面的請求就不會轉發到該節點上，並持續檢查幾點的狀態。在淘寶自己的 tengine 上是自帶了該模塊。
upstream backend {
sticky;
server 192.168.1.225:8080 weight=2;
server 192.168.1.226:8081 weight=1 max_fails=2 fail_timeout=30s ;
server 192.168.1.227:8080 weight=1 max_fails=2 fail_timeout=30s ;
server 192.168.1.227:8081;
check interval=5000 rise=2 fall=3 timeout=1000 type=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;
allow 192.168.1.0/24;
deny all;
}
}
nginx_upstream_check_module 對name這個負載均衡條目中的所有節點，每個5秒檢測一次，請求2次正常則標記 realserver狀態為up，如果檢測 3 次都失敗，則標記 realserver的狀態為down，超時時間為1秒。check指令只能出現在upstream中： interval ： 向後端發送的健康檢查包的間隔。 fall ： 如果連續失敗次數達到fall_count，服務器就被認為是down。 rise ： 如果連續成功次數達到rise_count，服務器就被認為是up。 timeout ： 後端健康請求的超時時間。 default_down ： 設定初始時服務器的狀態，也就是一開始服務器認為是不可用，要等健康檢查包達到一定成功次數以後才會被認為是健康的。 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 的狀態是健康的。 項目地址：https://github.com/yaoweibin/nginx_upstream_check_module 。 4、 proxy緩存的使用 緩存配置如下
http {
proxy_temp_path /usr/local/nginx-1.6/proxy_temp;
proxy_cache_path /usr/local/nginx-1.6/proxy_cache levels=1:2 keys_zone=cache_one:100m inactive=2d max_size=2g;
server {
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_valid 200 304 301 302 8h;
proxy_cache_valid 404 1m;
proxy_cache_valid any 2d;
proxy_cache_key $host$uri$is_args$args;
expires 30d;
}
location ~ /purge(/.*) {
allow 127.0.0.1;
allow 192.168.1.0/24;
deny all;
proxy_cache_purge cache_one $host$1$is_args$args;
error_page 405 =200 /purge$1;
}
}
}
清除緩存 上述配置的proxy_cache_purge指令用於方便的清除緩存，需要ngx_cache_purge 模塊 echo -e 'PURGE / HTTP/1.0\r\n' | nc http:/example.com/purge/path echo -e 'GET /purge/ HTTP/1.0\r\n' | nc http:/example.com/purge/path
