【Nginx】心跳检测之实战nginx_upstream_check_module模块

一、Nginx心跳检测问题

​       Nginx自带的针对后端节点健康检查的功能比较简单，主要是通过默认自带的ngx_http_proxy_module 模块和ngx_http_upstream_module模块中的相关指令来完成。实际上，nginx不算是自带健康检查的功能，而是当后端节点出现故障时，会切换到健康节点来提供访问。

​       如下，是一段我们现在常用的配置

upstream server_meeting_join {
    server manager-master:9884 weight=1 max_fails=5 fail_timeout=10s;
    server manager-slave-1:9884 weight=1 max_fails=5 fail_timeout=10s;
    server manager-slave-2:9884 weight=1 max_fails=5 fail_timeout=10s;
}

​       权重为1表示请求会依次轮询这三个节点，而max_fails则是设定Nginx与服务器通信的尝试失败的次数，此处设为5，则表示如果失败的次数达到5次，Nginx就认为服务器不可用。但是这样会带来一个问题，如果后端有不健康节点，负载均衡器依然会先把该请求转发给该不健康节点，尝试5次，然后再转发给别的节点，这样就会浪费一次转发，可能会造成响应时间过久。

 

二、Tengine的健康检查

​       区别于nginx自带的非主动式的心跳检测，淘宝开发的tengine自带了一个提供