nginx 健康检查

标签：col   参数详解   就是   stat   bsp   nginx   代理   count   后端   

自带健康检查配置

upstream backend{
　　server 127.0.0.1:8020 max_fails=2 fail_timeout=40s;    #在40s 时间内有两次后端服务连接失败就判断后端服务不可用
　　server 127.0.0.1:8021 max_fails=1 fail_timeout=40s;
}

处理过程

1、Nginx 在代理请求过程中会自动的监测每个后端服务器对请求的响应状态，如果某个后端服务器对请求的响应状态在短时间内累计一定失败次数时，Nginx 将会标记该服务器异            常。就不会转发流量给该服务器。 不过每间隔一段时间 Nginx 还是会转发少量的一些请求给该后端服务器来探测它的返回状态。 以便识别该服务器是否恢复。
      后端服务器不需要专门提供健康检查接口，不过这种方式会造成一些用户请求的响应失败，因为 Nginx 需要用一些少量的请求去试探后端的服务是否恢复正常。
2、这样有一个缺点是，nginx是被动地进行健康检查，也就是当有请求过来时，且请求打到A服务上时才能得知A服务的状态，如果A服务异常还要转发一次，效率受到影响。

第三方模块

安装nginx_upstream_check_module

location /{
　　proxy_pass http://cluster;
}
upstream cluster {
　　server 127.0.0.1:8181;
　　server 127.0.0.1:8182;

#http健康检查相关配置
check interval=3000 rise=2 fall=3 timeout=3000 type=http;

#/health/status为后端健康检查接口
check_http_send "HEAD /health/status HTTP/1.0\r\n\r\n";
check_http_expect_alive http_2xx http_3xx;
}

参数详解：

interval: 向后端发送的健康检查包的间隔，单位为毫秒
rsie: 如果连续成功次数达到rise_count，服务器就被认为是up
fall: 如果连续失败次数达到fall_count，服务器就被认为是down
timeout: 后端健康请求的超时时间，单位为毫秒
type: 健康检查包的类型，支持tcp、ssl_hello、http、mysql、ajp

Tips

这种是主动模式，根据配置频率定期检查达到判断条件就做出判定。需要nginx 开通额外的接口，有一点资源开销。

nginx 健康检查

标签：col   参数详解   就是   stat   bsp   nginx   代理   count   后端   

原文地址：https://www.cnblogs.com/fanggege/p/13192563.html