Nginx：max_fail和fail_timeout没那么简单

前言

今天遇到了一个nginx的问题，稍微深入了解了一下nginx的原生健康检测机制，就在那一刻才发现自己太过迷恋tengine的http_upstream_check_module了，对原生的健康检测有误解。

我一直认为：原生的nginx只能做tcp检测。

我一直认为：原生的nginx在检测后端服务失败后，就会将后端节点踢掉。

我一直认为：fail_timeout是每次检测的超时时间，max_fail是检测的次数。

全NM是误解，C了。

max_fail和fail_timeout

理解

官方文档的位置 https://nginx.org/en/docs/http/ngx_http_upstream_module.html

#样例：

upstream backend {
    server backend1.example.com weight=5;
    server 127.0.0.1:8080       max_fails=3 fail_timeout=30s;
    server unix:/tmp/backend3;

    server backup1.example.com  backup;
}

max_fails：是失败次数；

fail_timeout:  fail_timeout时间内如果失败了max_fails次，就会将节点标记为不可用。不可用的时间为fail_timeout 。 这就轮回起来了。

当max_fails为0的时候，就相当于关闭健康检测了。

怎么判断失败呢

有一个参数 proxy_next_upstream ，他的默认值是error和timeout,  也就是说当建立连接的时候超时或者是报错，就认为这个节点失败的。

我们此处可以看到也有一些http的状态检测的手段，所以说原生的健康检测也能做七层的检测。

超时时间

既然超时算是失败，那么超时时间是多少呢？这个就比较讲究了。

由proxy_connect_timeout（默认60s）和 net.ipv4.tcp_syn_retries （操作系统的，默认是6）这两个参数中较小的决定。

net.ipv4.tcp_syn_retries是当upstream中的server不返回ack的时候，重传syn的次数，默认是6次，6次的耗时是：1s,2s,4s,8s,16s,32s。 然后64s 后尝试另一个server。这样加起来差不多2m左右。

我们最好使用proxy_connect_timeout和proxy_send_timeout(这个我目前还不确定，会不会增加失败次数）来决定超时时间。

这两个值我觉得设置比较小就可以，因为后端服务如果在几秒内还没有接收请求或者建立连接，说明它已经很忙了，我们就可以尝试其他的server，或者返回给前端 502（前端可以设置一些策略，比如重试+按钮转圈+美好的提示等）来提供客户的体验，这样比等着好，因为用户越等越急，可能会暴躁的连击几下按钮，服务就更慢了。

fail_timeout要根据proxy_connect_timeout 和你的服务性能来配置。

如果你的服务平均响应时长是30s，而你的proxy_connect_timeout是5s，那么你接收到的响应肯定都是504 。

如果proxy_connect_timeout是10s，fail_timeout设置了一个1s, 那么这个节点永远不会被标记为不可用，当服务hang住的时候，你每次请求都要等待proxy_connect_timeout后才能尝试下一个server。

proxy_next_upstream_timeout 

这个参数意思是：在上一个server失败了以后，需要等待proxy_next_upstream_timeout时间后，再尝试下一个server。

一个节点的情况

当upstream下只配置一个server的时候，这个server不会被标记为不可用，如果这个节点hang住了，你每次请求都要等待超时。 当你的proxy_connect_timeout比较大的时候，就更悲催了。别问我是怎么知道的。。。555....

http_upstream_check_module

# http check
upstream student-service-api {
        server 172.26.34.101:9050;
        check interval=3000 rise=2 fall=5 timeout=1000 type=http;
        check_http_send "HEAD /health/check/status HTTP/1.0\r\n\r\n";
        check_http_expect_alive http_2xx http_3xx;
}

upstream  nerf {
    server 172.16.0.249:8091 weight=1;
    server 172.16.1.246:9019 weight=4;
    check interval=1000 rise=2 fall=5 timeout=10000 type=tcp;
}

这是tengine的健康检测模块，他和nginx原生额最大区别就是，他是主动检测的。所以，他不会出现上面一个节点不可能用时，仍然要等待超时的问题。再就是节点不可用的时候，他会打印error l日志，对于用户来说比较友好。

如何模拟服务hang的情况

一个比较无脑的方法：

# 记得 net.ipv4.ip_forward = 1
docker run -itd docker.io/centos:7 -p 10811:10811 bash

然后进入容器：

python -m SimpleHTTPServer 10811

然后回到服务器上

iptables -F

然后10811服务就会hang住了。

如何模拟500报错的服务的情况

# 记得 net.ipv4.ip_forward = 1
docker run -itd docker.io/centos:7 -p 10811:10811 bash

然后进入容器，创建一个python脚本

from SimpleHTTPServer import SimpleHTTPRequestHandler
import BaseHTTPServer
import sys

class CustomHTTPRequestHandler(SimpleHTTPRequestHandler):

    def do_GET(self):
        if self.path == '/':
            self.send_response(500)
            self.end_headers()
            self.wfile.write('Internal Server Error')
        else:
            super(CustomHTTPRequestHandler, self).do_GET()

def run(server_class=BaseHTTPServer.HTTPServer, handler_class=CustomHTTPRequestHandler):
    server_address = ('', 10811)
    httpd = server_class(server_address, handler_class)
    print 'Starting httpd on port %d...' % server_address[1]
    httpd.serve_forever()

if __name__ == '__main__':
    run()

然后执行脚本，就可以了。

##

祝你好运

# 有问题可以进群聊聊

614809646  qq群->数字人和tts,运维、开发等等