Nginx 的 upstream 模块会实现所谓的被动健康检查,也就是利用 max_fails 机制来实现,如果请求后端 upstream peer出现一些错误,当错误的累计次数达到 max_fails,那么该 upstream peer 会被 Nginx 摘掉 fail_timeout 时间,在这个时间内,这个 upstream peer 节点禁止对外提供服务。
需要重点注意的是 fails 是一个区间内失败的累加值,也就是在 fail_timeout 的这个时间区间内,两个错误之间即使有成功的请求,fails 也依然会进行累加计算。更为精确的表述这个功能细节如下:
层级我们线上的通用配置是参考官方的示例配置 max_fails=3 fail_timeout=30s;
,这个配置表示只要 30s 内出现了 3 次错误,那么就会被摘除 30s;这种配置在低流量下是没有明显问题的,但是我们线上的服务 QPS 都很高,至少都是万级别以上,针对这么高的 QPS ,这种配置显然不合理,因为高 QPS 的场景下,偶尔出现几个异常错误是常见的,那么这种情况下,一般可以通过其他机制来保证错误的处理。但是我们在高 QPS 的情况下, Nginx 的 upstream 是这样的配置就会使得服务出现一些毛刺,这也是我们曾经线上出现的实际问题。
经过分析讨论,fail_timeout 继续采用 Nginx 官方默认配置(注意这里是默认配置而不是他们的 sample 示例配置)的 10s,但是max_fails 需要调高,特别是对于后端 upstream 请求比较大的场景;目前我们的通用最佳实践配置是 fail_timout=10s max_fails=20
;如果 QPS 进一步增加,或者后端节点数减少,那么 max_fails 可以适当进一步调高。
当然,我们为了保证服务质量,仅仅依靠调整 fail_timout 和 max_fails 是无法保证的,因此还必须要同时引入 nginx_upstream_check_module 主动健康检查模块,这样才能保证我们服务的 SLA。
fail_timout=10s max_fails=20 这个可以当做一个最佳实践
max_fails 机制 和 主动健康检查 的处理逻辑如下:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。