互联网大厂技术-Nginx-负载均衡探活max_fails和fail_timeout的设置、根据参数转发upstream

目录

一、max_fails和fail_timeout的设置

二、max_fails 和 fail_timeout 的功能详解

三、max_fails 机制 和 主动健康检查 机制需要共存的原因

一、max_fails和fail_timeout的设置

Nginx负载均衡max_fails和fail_timeout的设置作用,直接贴配置上，看干货

server {
listen 80;
server_name xxxx.ikong.com;
location / {
                proxy_pass http://$pool;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
}
upstream loadbalance_1 {
       server 192.168.20.216:8080 weight=8 max_fails=1 fail_timeout=30s;
       server 192.168.20.217:8080 weight=1 max_fails=1 fail_timeout=30s;
       server 192.168.20.218:8080 weight=1 max_fails=1 fail_timeout=30s;
}

upstream loadbalance_2 {
        server 192.168.20.211:8081 weight=3;
        server 192.168.20.212:8081 weight=3;
        server 192.168.20.213:8089 weight=2;
        server 192.168.20.214:8089 weight=2;
}

map $http_header_param_key $pool {
     default "loadbalance_2";
     header_param_key_3 "loadbalance_1";
     header_param_key_1 "loadbalance_1";
     header_param_key_2 "loadbalance_1";
}

这里会把 header中 param_key 这个参数拿出来跟$pool 中设置的header_param_key的key进行比较，命中的如：header_param_key_3 会转发到loadbalance_1，没有命中的会转发到默认loadbalance_2；

 weight=8 max_fails=1 fail_timeout=30s;

weight 作用：流量切割

max_fails=1 fail_timeout=30s; 转发给后端服务时，若发现后端服务故障，则将请求转发给其他节点进行处理，并将服务器标记为故障、在30s时间内不再转发给故障服务器。30s后重试转发给故障服务器，若仍旧不成功则重复刚才的操作；

整体来看不影响试错的请求；

二、max_fails 和 fail_timeout 的功能详解

Nginx 的 upstream 模块会实现所谓的被动健康检查，也就是利用 max_fails 机制来实现，如果请求后端 upstream peer出现一些错误，当错误的累计次数达到 max_fails，那么该 upstream peer 会被 Nginx 摘掉 fail_timeout 时间，在这个时间内，这个 upstream peer 节点禁止对外提供服务。

需要重点注意的是 fails 是一个区间内失败的累加值，也就是在 fail_timeout 的这个时间区间内，两个错误之间即使有成功的请求，fails 也依然会进行累加计算。更为精确的表述这个功能细节如下：

1. 如果在 T0 时刻出现了一个错误，那么 fails = 1；

2. 在 T0 ~ T0 + fail_timeout 的时间区间内：

   1.  如果没有出现错误，那么 fails 会重置为 0；

   2. 如果出现了一个新错误，比如在 T1 时刻出现一个新的错误，那么 fails 会继续累加，fails = 2

3. 接着会重新以新的时间区间 T1 ~ T1 + fail_timeout 开始统计但是 fails 值却是继续累加，如果这个时间区间又有一个新的错误，那么 fails = 3

4. 直到 T2 时刻，出现了新的错误并 fails >= max_fails，那么 peer 节点会被摘除，在 T2 ~ T2 + fail_timeout 这个时间内，节点就无法对外提供服务，并且重置 fails 为 0，然后开启新的一轮检测

三、max_fails 机制 和 主动健康检查 机制需要共存的原因

max_fails 机制 和 主动健康检查 的处理逻辑如下：

1. max_fails 是访问 upstream 的所有接口请求错误都算（抛开 proxy_next_upstream 指定的一些错误类型），这样的话，当 QPS 很大的情况下，比如 3-5w QPS ；那业务访问这个 upstream，也许只在 1s 内就能达到 max_fails 次数，然后就会摘掉 fail_timeout 时间，这样就可以很快摘掉

   1. 这个的问题是，只有把流量打进去，才能知道是否有异常，这个对业务是有损的。

2. 主动健康检查，是固定频率检测固定接口，比如我每隔 3s 检测一次，然后失败 2 次就认为节点不可用，但是这个最长耗时需要 6s 才能摘掉

   1. check 主动检测，需要长达 6s 才能摘掉，在高并发的情况下，无法接受秒级别的失败，很多业务方会敏感，我们要去降低影响面，max_fails 相当于增加了一个熔断机制。

   2. 这个的优势是提前检测，不涉及业务本身的流量；但是劣势是需要一个时间范围，不能马上摘除。

3. 共存就是为了同时工作，从不同的角度来检测健康状态，两者的优劣进行互补，刚好相互弥补缺陷，从而尽快剔除有问题的节点，提高服务质量。