搭建个实验环境，环境如下：
-
Nginx
-
PHP-FPM(x2)
nginx 通过 fast-cgi 将 php 请求转发到 PHP-FPM，这里 PHP-FPM 服务即上游服务，设置 upstream，负载 PHP-FPM
upstream 按照默认配置，即 max_fails=1，fail_timeout=10
现在通过 tailf 分别监听两个 PHP-FPM 日志
请求4次，因为是默认轮询的，所以可以看时间，轮询将请求分发到两个PHP-FPM上游
可以从上面的日志中看到，按照轮询规则，下次请求应该落到 PHP-FPM2 上面，接着，关掉 PHP-FPM1，继续请求
可以看到，PHP-FPM1肯定是不响应了，PHP-FPM2正常响应，接着看下Nginx日志
可以看到，关掉 PHP-FPM1 后，发起的请求，本来第二次请求(17:49:58)应该分发到 PHP-FPM1 的，然后从 Nginx 错误日志可以看到，连接 PHP-FPM1 失败，这里只做了一次失败尝试，然后 Nginx 将请求转发到 PHP-FPM2 处理了。
接着将 max_fails 设置为2，继续上面的请求
开启 PHP-FPM1，继续请求，两个负载轮询转发请求
接着继续关掉 PHP-FPM1，连续发起多次请求，查看日志
所有请求都在 PHP-FPM2上，看 Nginx 错误日志
两次轮询到PHP-FPM1的时候，失败，之后不会再将请求分发到 PHP-FPM1 上游服务
接着，不开启 PHP-FPM1，继续发起多次请求，由于默认的 fail_timeout=10，所以在上面的失败检测 10s 之后再次发起请求，查看日志
继续分发到 PHP-FPM2，接着看 Nginx 错误日志可以看到，过了 fail_timeout 的时间后，Ngxin 会再次将请求发往 FPM-PHP1 进行尝试，尝试2次失败后，在 fail_timeout 时间内，不会再将请求分发
这里有几个误区：
-
Nginx 记录了连接上游失败，这个请求就返回错误请求，或这个请求丢失没处理
这个理解是错误的，Nginx 只是记录了失败的请求到日志，并将这个请求又转发到了可用的其他上游服务，知道所有上游都不可用时，才会返回错误状态
-
max_fails 是指连续请求失败的次数
max_fails 是在 fail_timeout 指定的时间内的失败次数，请求还是按照配置的负载均衡算法来走，并不是第一次请求失败之后，继续将这个请求在尝试一次，达到失败次数之后，标记为不可用
-
fail_timeout 越短越好
当访问量大的时候，fail_timeout 设置太短，会导致不断的尝试与不可用上游的连接，耗费大量的 tcp 资源进行连接
-
fail_timeout 越长越好
当访问量大的时候，fail_timeout设置太长，会导致负载不均衡，有可能会击穿某个上游后端，达不到负载的效果。