nginx中的健康检查方案

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，也就是一开始服务器认为是不可用，要等健康检查包达到一定成功次数以后才会被认为是健康的

健康检查包的类型,常用(tcp\http)：

• tcp：简单的tcp连接，连接成功，就说明后端正常（网络层探测，通过发送SYN握手报文来检测服务器端口是否存活）。
• http：发送HTTP请求，通过后端的回复包的状态来判断后端是否存活
• 不常用:ajp\ssl_hello\mysql\fastcgi
• 说明:(将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.0\r\n\r\n"; #默认用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.0\r\n\r\n"）注意:请求的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.0\r\n\r\n"; # /url指提供健康检查的url
    check_http_expect_alive http_2xx http_3xx;
}

server 中配置。用于界面显示后端健康状态
location /status {
check_status;
access_log off;
}

总结

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。