ngx_http_proxy_module模块(自带) 超时时间设置
无特别场景需求都可直接采用默认60s
- 语法:proxy_connect_timeout “time“;
- 默认值:proxy_connect_timeout 60s;
- 作用域:http, server, location
该指令设置与upstream server的连接超时时间,有必要记住,这个超时不能超过75秒。这个时间Nginx与上游服务器
尝试建立连接,如果60s内都没有建立成功,则会放弃这个连接。
- 语法:proxy_read_timeout “time“;
- 默认值:proxy_read_timeout 60s;
- 作用域:http, server, location
定义从后端服务器读取响应的超时。
此超时是指相邻两次读操作之间的最长时间间隔,而不是整个响应传输完成的最长时间。
如果后端服务器在超时时间段内没有传输任何数据,连接将被关闭(连接成功后_等候后端服务器响应时间_其实已经进入后端的排队之中等候处理(也可以说是后端服务器处理请求的时间))。
- 语法:proxy_send_timeout time;
- 默认值:proxy_send_timeout 60s;
- 作用域:http, server, location
设置将请求传输到代理服务器的超时。仅在两个连续的写操作之间设置超时,而不是为整个请求的传输。
如果代理服务器在此时间内未收到任何内容,则关闭连接。(后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据)。
- 语法:proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_404 | off …;
- 默认值:proxy_next_upstream error timeout;
- 作用域:http, server, location
后端返回状态码:指定在何种情况下一个失败的请求应该被发送到下一台后端服务器
1、nginx 被动check 方法
Nginx(自带)有健康检查模块:ngx_http_upstream_module,可以做到基本的健康检查
参数:
- max_fails:失败尝试最大次数;超出此处指定的次数时,server将被标记为不可用,默认为1
- fail_timeout:后端服务器标记为不可用状态的连接超时时长,默认10s
- backup:将服务器标记为”备用”,即所有服务器均不可用时才启用
例如:
server x.x.x.x:8080 max_fails=3 fail_timeout=30s;` server x.x.x.x:8080 max_fails=3 fail_timeout=30s;`
说明:
代表在30秒内某一应用失败3次,认为该应用宕机,后等待30秒,这期间内不会再把新请求发送到宕机应用,而是直接发到正常的那一台,等待的这30秒时间到后再有请求进来继续尝试连接宕机应用且仅尝试1次,如果还是失败,则继续等待30秒…以此循环,直到恢复。`
缺点:
Nginx只有当有访问时后,才发起对后端节点探测。
如果本次请求中,节点正好出现故障,Nginx依然将请求转交给故障的节点,然后再转交给健康的节点处理。
所以不会影响到这次请求的正常进行。
但是会影响效率,因为多了一次转发,而且自带模块无法做到预警。
2、nginx 主动check 方法
nginx_upstream_check_module模块对后端节点做主动健康检查(淘宝开发)
主动check:心跳检测,为非业务流量,nginx本身发起健康检测请求。
注意:check模块版本和Nginx版本要求有限制。做补丁包的时候注意版本选择
check指令只能出现在upstream中:
- interval:向后端发送的健康检查包的间隔。
- fall:如果连续失败次数达到fall_count,服务器就被认为是down。
- rise:如果连续成功次数达到rise_count,服务器就被认为是up。
- timeout:后端健康请求的超时时间。
- default_down:设定初始时服务器的状态,如果是true,就说明默认是down的,如果是false,就是up的。默认值是true,也就是一开始服务器认为是不可用,要等健康检查包达到一定成功次数以后才会被认为是健康的
健康检查包的类型,常用(tcphttp):
- tcp:简单的tcp连接,连接成功,就说明后端正常(网络层探测,通过发送SYN握手报文来检测服务器端口是否存活)。
- http:发送HTTP请求,通过后端的回复包的状态来判断后端是否存活
- 不常用:ajpssl_hellomysqlfastcgi
- 说明:(将HTTP模式的负载均衡修改为TCP模式后,负载均衡将只检查监听端口状态,不检查HTTP状态,会导致负载均衡无法实时获知HTTP应用是否出现问题。)
TCP模式配置:
upstream xxxx { server ip:port; server ip:port; check interval=5000 rise=2 fall=3 timeout=1000 type=tcp; }
HTTP模式配置:(需要提供一个健康检查的url)
upstream xxxx { server ip:port; server ip:port; check interval=5000 rise=2 fall=3 timeout=1000 type=http; check_http_send "HEAD / HTTP/1.0rnrn"; #默认用HEAD方式 请求缺省页 check_http_expect_alive http_2xx http_3xx; }
说明:
每个5秒检测一次(单位为毫秒),请求2次正常则标记 realserver状态为up,如果检测 3 次都失败,则标记 realserver的状态为down,超时时间为1秒(单位为毫秒)。
- check_http_send: http 请求方式 如:(”GET /index.html HTTP/1.0rnrn”)注意:请求的uri不宜过大
- check_http_expect_alive: 定义健康的状态码
server 中配置可界面显示后端健康状态 location /status { check_status; access_log off; }
3、目前环境配置建议:为保证业务流量无影响,优先采用主动check方式
后端应用未配置(提供)健康检查url情况
upstream xxxx { server ip:port; server ip:port; check interval=5000 rise=2 fall=3 timeout=1000 type=tcp; }
后端提供健康检查url 情况
upstream xxxx { server ip:port; server ip:port; check interval=5000 rise=2 fall=3 timeout=1000 type=http; check_http_send "HEAD /url HTTP/1.0rnrn"; # /url指提供健康检查的url check_http_expect_alive http_2xx http_3xx; }
server 中配置。用于界面显示后端健康状态 location /status { check_status; access_log off; }
总结
以上为个人经验,希望能给大家一个参考,也希望大家多多支持IT俱乐部。