nginx的被动健康检查参数nginx的ngx_stream_upstream模块包含被动健康检查的功能当某个后端服务器不可用时将其自动摘除。有一些参数来控制被动健康检查主要有两个 max_fails 和 fail_timeout。其中 max_fails 比较好理解达到指定的失败次数就将这个后端服务器剔除。而 fail_timeout 起初我理解错了理解成了当后端服务器无响应时的最大等待时间超过此时间认为失败。而其实际意义甚至具有双重含义在 Nginx 被动健康检查中fail_timeout 参数有两个核心作用它既是一个统计周期也是一个惩罚时长。统计周期Nginx 会统计在这个时间段内对某台后端服务器发生的“失败”次数。惩罚时长当失败次数达到预设的 max_fails 阈值后Nginx 会将该服务器标记为“不可用”并在接下来的 fail_timeout 时间段内不再向其转发请求。下面来测试其实际效果nginx配置upstream apibackend { server 10.10.10.215:8000 max_fails1 fail_timeout30s; server 10.10.10.216:8000 max_fails1 fail_timeout30s; server 10.10.10.217:8000 max_fails1 fail_timeout30s; } server { listen 80; server_name localhost; location /api/ { proxy_pass http://apibackend/; } }将215机器的后端进程挂起kill -19 $(pgrep gohello) ps aux | grep gohello # root 896856 0.0 0.1 1229524 4852 pts/1 Tl 19:15 0:00 gohello请求nginx进行测试set m # 关闭作业监控 count0 while [ $count -lt 36 ]; do bash -c echo -n $(date); curl -so /dev/null http://127.0.0.1/api/; echo -n -- ; echo -n $(date); echo sleep 5 ((count)) done set -m # 恢复作业监控结果如图黄色表示请求处理中未返回。红色表示请求返回但间隔了60秒。图中现象说明1、虽然 fail_timeout30s但在30s内对挂起后端的请求并未处理完成也不被认为失败而是等待请求返回就是max_fails的失败计数未计算。2、在nginx默认的60s超时后超时时间可以通过proxy_read_timeout等控制请求因超时而失败注意nginx对外的请求并不会失败会转移到下一台后端此时fails开始计数我们设置的 max_fails1且满足在fail_timeout的30s内所以nginx把挂起的后端摘除并维持摘除状态fail_timeout30s。3、如图中红色框所示因为连续的fails计数所以实现了连续的摘除不断的把摘除状态延后30s。4、不管proxy_read_timeout和fail_timeout相对大小如何都会出现前proxy_read_timeout时间内会轮询到挂起的机器之后的fail_timeoutproxy_read_timeout时间内不会轮询到挂起机器如此反复。5、如上只有fail_timeout远大于proxy_read_timeout才有意义如fail_timeout300s, proxy_read_timeout2s缺点是故障恢复慢。但假如fail_timeout2s, proxy_read_timeout300s那几乎没起到作用在接近一半的时间里1/3的请求会很慢。nginx被动健康检查相关源码nginx-1.22.1为例// src/stream/ngx_stream_upstream_round_robin.c static ngx_stream_upstream_rr_peer_t * ngx_stream_upstream_get_peer(ngx_stream_upstream_rr_peer_data_t *rrp) { time_t now; uintptr_t m; ngx_int_t total; ngx_uint_t i, n, p; ngx_stream_upstream_rr_peer_t *peer, *best; now ngx_time(); best NULL; total 0; #if (NGX_SUPPRESS_WARN) p 0; #endif for (peer rrp-peers-peer, i 0; peer; peer peer-next, i) { n i / (8 * sizeof(uintptr_t)); m (uintptr_t) 1 i % (8 * sizeof(uintptr_t)); if (rrp-tried[n] m) { continue; } if (peer-down) { continue; } if (peer-max_fails peer-fails peer-max_fails now - peer-checked peer-fail_timeout) { continue; } if (peer-max_conns peer-conns peer-max_conns) { continue; } peer-current_weight peer-effective_weight; total peer-effective_weight; if (peer-effective_weight peer-weight) { peer-effective_weight; } if (best NULL || peer-current_weight best-current_weight) { best peer; p i; } } if (best NULL) { return NULL; } rrp-current best; n p / (8 * sizeof(uintptr_t)); m (uintptr_t) 1 p % (8 * sizeof(uintptr_t)); rrp-tried[n] | m; best-current_weight - total; if (now - best-checked best-fail_timeout) { best-checked now; } return best; }nginx的主动健康检查方式1、开源的第三方模块nginx_upstream_check_module缺点是需要重新编译ningx因为只支持静态编译不支持动态编译so。2、Nginx Plus (官方商业版) 的 health_check 指令缺点是商用需要花钱。3、lua-resty-upstream-healthcheck方案缺点是需要安装LuaJIT和lua‑nginx‑module、lua‑upstream‑nginx‑module或直接安装OpenResty。--end--