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