关于 NGINX 的 upstream 配置的 fail_timeout=0 参数的意义
Livid · 2016-12-23 16:54:53 +08:00 · 15130 次点击这是一个创建于 2899 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天在下面的这个 NGINX 例子配置文件里里看到一个有意思的观点，就是如果后端是一个动态程序，那么 upstream 的 fail_timeout 应该设置为 0 ：
https://bogomips.org/unicorn/examples/nginx.conf
upstream app_server {
...
server 192.168.0.7:8080 fail_timeout=0;
...
}
fail_timeout 的默认值是 10 秒，配合默认值为 1 的 max_fails 参数，意思是如果在 fail_timeout 期间后端失败了 max_fails 次，那么就将这个后端标识为不可用，在接下来的 fail_timeout 期间， NGINX 不会再将请求分配到这个后端。
如果将 fail_timeout 设置为 0 ，那么无论后端失败了多少次， NGINX 会继续把请求分发到这个后端服务器地址。
如果后端是一个动态程序，比如 Python 或者 Node.js ，那么就应该将 fail_timeout 设置为 0 ，这样即使后端偶尔抛出一个 500 错误，那么也不应该暂停服务。在动态应用中，出现偶尔的 500 错误是很正常而且几乎无法避免的。如果后端因为某些更严重的原因一直出现 500 错误，那么这种问题其实也是任何 NGINX 配置都解救不了的。
fail_timeout 设置为 10 秒或者更长时间，可能对于静态的后端会更有意义。因为静态的后端通常很难出现 500 错误。如果出错了，一般也都是因为一些更麻烦的问题，比如硬盘坏了，或者内存满了之类，这种时候通过 fail_timeout 的值来暂时避免将请求发送到有问题的静态后端，是有意义的。
15 条回复 • 2017-07-25 10:14:13 +08:00
 |
1
ctsed 2016-12-23 16:58:39 +08:00 via iPhone
动态程序也可能硬盘坏了内存满了
|
 |
2
glasslion 2016-12-23 17:04:00 +08:00
这样的话，对动态程序难道不是增大 max_fails 更合理吗？
|
 |
3
finab 2016-12-23 17:04:11 +08:00 via iPhone
|
 |
4
est 2016-12-23 17:09:28 +08:00  2
这是一个坑点。仔细读文档才会发现。专业的 sa 如果不知道这个是个扣分点。
还有一个点就是用 http 1.1 和 connection keep-alive 可以提高效率。 nginx 默认给 upstream 是 connection: close |
 |
6
qq286735628 2016-12-23 17:18:32 +08:00
既然认为后端的 500 是偶发现象可以接收，那就应该加大 max_fails 来支持这种偶发的。
否则真的连续故障了， nginx upstream 的自动剔除机制就废了 |
 |
7
lhbc 2016-12-23 17:23:57 +08:00
楼主这个理解是不正确的
1. 假如 upstream 只有一个 server ，那 max_fails 和 fail_timeout 都是没用的。 2. 假如 upstream 有多个 server ，那超过了 max_fails 次错误后，在 fail_timeout 时间内会摘除这个 server 如果全部 server 都失败， nginx 会清空这个状态，轮询所有服务器 就是说，无论怎么配置， nginx 都会保证 upstream 里有可用的 server |
|
8
lhbc 2016-12-23 17:39:16 +08:00
@qq286735628 +1
多 server 的回源，偶发异常，加大 max_fails 就可以了，要保证 fail_timeout 能起到作用； 如果是单点回源，这两个参数就不用写了。 无论是纯静态还是动静混合的后端 应该用 proxy_next_upstream 和 proxy_cache_use_stale 保证静态资源的可用率 |
 |
9
Livid MOD OP 有的时候情况是这样的，后端其实还有处理能力，但是因为 fail_timeout 和 max_fails 的值不理想，而被浪费了。这也是为什么有时候后端明明还活着，但是错误日志里却出现 no live upstreams while connecting to upstream
|
 |
10
wupher 2016-12-23 17:55:51 +08:00
受教，最近正好碰到类似问题。晚上回家试一下。
|
 |
11
banxi1988 2016-12-23 18:06:59 +08:00
之前没有配置过 fail_timeout
看来之后要注意下这一点了. 我的后端还是比较有可能抛出 500 错误的. |
 |
12
fangpeishi 2016-12-23 18:10:54 +08:00
可以再配合 proxy_next_upstream ，对抛 500 的请求再转给下一个 server 。
Syntax: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 | http_403 | http_404 | non_idempotent | off ...; Default: proxy_next_upstream error timeout; Context: http, server, location Specifies in which cases a request should be passed to the next server: https://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_next_upstream |
 |
13
justfly 2016-12-23 19:33:25 +08:00 2
楼主的方法是错误的。
问题关键是不应该让 nginx 认为 500+的 http code 是错误。应当使用 proxy_next_upstream 来决定什么时候决定换 backend 。 The cases of error, timeout and invalid_header are always considered unsuccessful attempts, even if they are not specified in the directive. The cases of http_500, http_502, http_503 and http_504 are considered unsuccessful attempts only if they are specified in the directive. The cases of http_403 and http_404 are never considered unsuccessful attempts. 设置 fail_timeout 为 0 当某个后端阻塞 会有很多不必要的尝试 进而影响吞吐量 |
|
14
Livid MOD OP 今天在某个生产环境中遇到了一个很难搞的 no live upstreams while connecting to upstream 错误，尝试了一下把 max_fails 和 fail_timeout 都设置为 0，貌似解决了。
之前是每次 upstream timed out 错误之后，就会跟一大串 no live upstreams while connecting to upstream （其实是因为这个时候 fail_timeout 的默认 10 秒等待），加入了这两个设置之后，现在只会有偶尔的 upstream timed out。 |
 |
15
keakon 2017-07-25 10:14:13 +08:00 1
看了下源码，nginx 发现连接超时、读取超时、status code >= 300 就会尝试下一个 upstream，如果它成功就换它响应，如果它失败就自己返回失败。
所以对于动态服务器，确实应该禁用。 |
Select Language