标签：必须 fastcgi air 就是 备份 read ip地址 业务 local
- 1. 前言
- 2. 配置示例及指令说明
- 2.1 配置示例
- 2.2 指令
- 2.3 upstream相关变量
- 3. 参数配置及测试
- 3.1 max_fails 和 fail_timeout
- 3.2 proxy_next_upstream
- 3.3 nginx 与后端web连接时间的三个参数
当 Nginx 作为反向代理使用的时候，upstream模块有着举足轻重的地位，官方解释：
2.1 配置示例
2.2 指令
指令名称: upstream
语法：upstream name { … }
默认值：none
使用环境：http
功能：该指令是一个组合型指令它描述了一组服务器，这组服务器将会被指令 proxy_pass 和 fastcgi_pass 作为一个单独的实体使用，它们可以将 server 监听在不同的端口，而且还可以同时使用TCP和UNIX套接字监听。服务器可以设置不同的权重，如果没有设置权重，那么默认会将其设置为 1 。
指令名称: ip_hash
语法：ip_hash
默认值：none
使用环境：upstream
功能：如果使用了该指令，那么将会导致客户端的请求以用户端IP地址分布在 upstream 中的 server 之间。它的关键技术在于对这个请求客户端IP地址进行哈希计算，这种方法保证了客户端请求总是能够传递到同一台后台服务器，但是如果该服务器被认定为无效，那么这个客户端的请求将会被传递到其他服务器，因此，这种机制是一个高概率将客户端请求总是连接到同一台服务器。
Nginx 的 upstream 支持 5 种分配方式，其中有三种为 Nginx 原生支持的分配方式，后两种为第三方支持的分配方式。
指令名称: server
语法：server name [parameters]
默认值：none
使用环境：upstream
功能：该指令用于设置服务器的 name，对于 name，可以使用域名、ip地址、端口或是 UNIX 套接字，如果一个域名被解析到多个 IP 地址，那么所有的 IP 地址都将会被使用。
可选的 parameters 如下：
2.3 upstream相关变量
变量名：$upstream_addr
功能：该变量表示了处理该请求的 upstream 中 server 的地址
变量名：$upstream_cache_status
功能：该变量出现在 Nginx 0.8.3 版本中， 可能的值如下：
变量名：$upstream_status
功能：该变量为 upstream 中 server 的响应状态
变量名：$upstream_response_time
功能：upstream server 响应的时间，单位为秒，能够精准到毫秒。如果有多个 server 响应回答，那么会用逗号和冒号分隔开
变量名：$upstream_http_$HEADER
功能：HTTP 协议头。例如：$upstream_http_host
参数相关说明介绍完毕，接下来重点测试部分参数：
max_fails 、fail_timeout 、proxy_next_status
1台反向代理（nginx/1.14.2）
2台后端web（apache+php）
首先，查看客户端 发起一次 连接请求的过程：
通过抓包，可以看到 浏览器 请求一次 nginx 反向代理：
3.1 max_fails 和 fail_timeout
max_fails - 检测出错的次数。
fail_timeout - 出错后，暂停server的时间。
配置如下图：
主机信息：
nginx: 192.168.118.15 web1: 192.168.118.16 web2: 192.168.118.17
（1）当 max_fails 为 0 ， fail_timeout 为 0
已知，upstream默认采用轮询的方式，web2服务关闭
通过浏览器快速刷新4次，分析如下：
首先查看 nginx 日志：
一共发起了 4 次连接请求，根据 upstream默认轮询方式，有两次都轮询到了 192.168.118.17 （服务关闭）上。
查看 web1（192.168.118.16）日志：
一共发起了 4 次请求，而 web1 接收到了 4 次，也就是这 4 次请求，都是 web1 来响应的。
为什么 4 次请求都是 web1 响应的呢？
通过上图，当 nginx 首次轮询到 web2 时，连接失败，web2 返回 RST，nginx会再次发起请求到 web1 。
总结：
max_fails = 0 and fail_timeout = 0 时，后端服务故障时，依然会轮询到故障主机，且没有暂停服务时间的限制。
（2） max_fails = 0 and fail_timeout = 5
已知，upstream默认采用轮询的方式，web2服务关闭， 配置如下：
通过浏览器快速刷新，分析如下：
nginx 日志
通过错误日志可以看出，当 upstream 没有设置 最大错误数（max_fails），无论后端server是否有效，都会轮询到该server上，fail_timeout 设置任何值都是无效的。
（3） max_fails = 3 and fail_timeout = 5
已知，upstream默认采用轮询的方式，web2服务关闭， 配置如下：
通过浏览器快速刷新，分析如下：
nginx 日志
通过配置最大失败连接数为 3 时，当后端web2服务关闭后，nginx首次会尝试 max_fails 次，如果仍然没响应，则暂停该server fail_timeout 秒，然后每隔 fail_timeout 时间后尝试一次，失败则继续暂停 fail_timeout 秒。
（4） max_fails = 3 and fail_timeout = 0
这种方式和 max_fails = 0 and fail_timeout = 3 测试结果一致，不在举例。
通过上面 max_fails 和 fail_timeout 测试，当要实现失败后暂停服务时，max_fails 和 fail_timeout 任何一项都不能为 0 。
在测试中，无论怎么刷新，nginx总是能够返回正常服务的server 数据，这是为什么？明明已经轮询到服务失效的节点，这里并没有定义任何的 proxy_next_upstream
解释：
针对nginx负载均衡upstream容错机制的使用说明
（1）nginx 的 upstream 容错
Nginx默认判断失败节点状态是以 和 timeout （上面的例子就为web2-timeout）状态为准，不以HTTP错误状态进行判断失败，因为HTTP只要能返回状态说明该节点还可以正常连接，除非添加了proxy_next_upstream指令设置对404、502、503、504、500和time out等错误进行转到备机处理。在next_upstream过程中，会对fails进行累加，如果备用机处理还是错误则直接返回错误信息（但404不进行记录到错误数，如果不配置错误状态也不对其进行错误状态记录）综述，nginx记录错误数量只记录timeout 、connect refuse、502、500、503、504这6种状态，timeout和connect refuse是永远被记录错误状态，而502、500、503、504只有在配置proxy_next_upstream后nginx才会记录这4种HTTP错误到fails中，当fails大于等于max_fails时，则该节点失效；
（2）nginx 处理节点失效和恢复的触发条件
nginx可以通过设置max_fails（最大尝试失败次数）和fail_timeout（失效时间，在到达最大尝试失败次数后，在fail_timeout的时间范围内节点被置为失效，除非所有节点都失效，否则该时间内，节点不进行恢复）对节点失败的尝试次数和失效时间进行设置，当超过最大尝试次数，则失效fail_timeout 时间，nginx每隔 fail_timeout时间尝试一次后端server 有没有恢复，直到所有后端服务失效，则返回错误页面给客户端；
（3）所有节点失效后 nginx 将重新恢复所有节点进行探测
如果探测所有节点均失效，备机也为失效时，那么nginx会对所有节点恢复为有效，重新尝试探测有效节点，如果探测到有效节点则返回正确节点内容，如果还是全部错误，那么继续探测下去，当没有正确信息时，节点失效时默认返回状态为502，但是下次访问节点时会继续探测正确节点，直到找到正确的为止。
（4）通过proxy_next_upstream实现容灾和重复处理问题
ngx_http_proxy_module 模块中包括proxy_next_upstream指令
语法: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_404 | off ...;
默认值: proxy_next_upstream error timeout;
上下文: http, server, location
error 表示和后端服务器建立连接时，或者向后端服务器发送请求时，或者从后端服务器接收响应头时，出现错误
timeout 表示和后端服务器建立连接时，或者向后端服务器发送请求时，或者从后端服务器接收响应头时，出现超时
invalid_header 表示后端服务器返回空响应或者非法响应头
http_500 表示后端服务器返回的响应状态码为500
http_502 表示后端服务器返回的响应状态码为502
http_503 表示后端服务器返回的响应状态码为503
http_504 表示后端服务器返回的响应状态码为504
http_404 表示后端服务器返回的响应状态码为404
off 表示停止将请求发送给下一台后端服务器
运用场景：
1）proxy_next_upstream http_500 | http_502 | http_503 | http_504 |http_404;
当其中一台返回错误码404,500...等错误时，可以分配到下一台服务器程序继续处理，提高平台访问成功率，多可运用于前台程序负载设置
2）proxy_next_upstream off
因为proxy_next_upstream 默认值: proxy_next_upstream error timeout;
场景：
当访问A时，A返回error timeout时，访问会继续分配到下一台服务器处理，就等于一个请求分发到多台服务器，就可能出现多次处理的情况，如果涉及到充值，就有可能充值多次的情况，这种情况下就要把proxy_next_upstream关掉即可
proxy_next_upstream off
案例分析（nginx proxy_next_upstream导致的一个重复提交错误）：
一个请求被重复提交，原因是nginx代理后面挂着2个服务器，请求超时的时候（其实已经处理了），结果nigix发现超时，有把请求转给另外台服务器又做了次处理。
解决办法：
proxy_next_upstream:off
3.2 proxy_next_upstream
语法: proxy_next_upstream error | timeout | invalid_header | http_500 | http_502 | http_503 | http_504 |http_404 | off ...;
默认值: proxy_next_upstream error timeout;
上下文: http, server, location
接下来，测试 proxy_next_upstream 是否能够定义失败的标准：
<?php header(‘RS:Web1‘); $t = 1; sleep($t); echo "sleep {$t}s<br>"; echo "web-1<br>"; ?>
<?php header(‘RS:Web2‘); header(‘http/1.1 500 Internal Server Error ‘); #$t = 5; #sleep($t); echo "sleep {$t}s<br>"; echo "web-2<br>"; ?>
nginx配置如下：
upstream 默认后端server失效标准： timeout 和 Connect refuse，在这里例子中，使用
proxy_next_upstream http_500 http_502 http_504
[root@localhost ~]# curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} http://192.168.118.15/test.php HTTP/1.1 200 OK Server: nginx/1.14.2 Date: Thu, 14 Mar 2019 10:53:51 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive X-Powered-By: PHP/5.4.16 RS: Web1 1.006:0.000:1.006
三次都是返回 200 状态，说明 proxy_next_upstream 已经将后端server 返回 500 状态的主机拦截为失效。
3.3 nginx 与后端web连接时间的三个参数
proxy_connect_timeout :后端服务器连接的超时时间_发起握手等候响应超时时间
proxy_read_timeout:连接成功后，等候后端服务器响应时间_其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间）
proxy_send_timeout :后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据
这里对 proxy_read_timeout 进行测试：
nginx 配置：
<?php header(‘RS:Web1‘); $t = 3; sleep($t); echo "sleep {$t}s<br>"; echo "web-1<br>"; ?>
<?php header(‘RS:Web1‘); $t = 5; sleep($t); echo "sleep {$t}s<br>"; echo "web-1<br>"; ?>
测试结果：
[root@localhost ~]# curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} http://192.168.118.15/test.php HTTP/1.1 504 Gateway Time-out Server: nginx/1.14.2 Date: Thu, 14 Mar 2019 11:27:59 GMT Content-Type: text/html Content-Length: 537 Connection: keep-alive ETag: "5c89b5df-219" 2.004:0.001:2.004
三次返回结果一致，每次请求均耗时 2秒，这是因为 proxy_read_timeout 设置为 2s ，而后端的程序: web1-sleep 3 、web2-sleep 5，都无法及时响应。
修改 proxy_read_time 为 3 秒，测试如下：
[root@localhost ~]# curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} http://192.168.118.15/test.php HTTP/1.1 200 OK Server: nginx/1.14.2 Date: Thu, 14 Mar 2019 11:33:30 GMT Content-Type: text/html; charset=UTF-8 Connection: keep-alive X-Powered-By: PHP/5.4.16 RS: Web1 3.004:0.001:3.004 [root@localhost ~]# curl -I -w %{time_total}:%{time_connect}:%{time_starttransfer} http://192.168.118.15/test.php HTTP/1.1 504 Gateway Time-out Server: nginx/1.14.2 Date: Thu, 14 Mar 2019 11:33:35 GMT Content-Type: text/html Content-Length: 537 Connection: keep-alive ETag: "5c89b5df-219" 3.005:0.001:3.005
当轮询到 web1 -sleep 3秒时，满足 proxy_read_timeout 返回 200 状态，当轮询到 web2 -sleep 5秒时，超过 proxy_read_timeout 返回 504 状态。
总结：
对于 max_fails 和 fail_timeout 必须连用，但是都不能为 0 ，否则失效检查被禁止，每次都会轮询到失败的节点
proxy_next_upstream 的使用一定要谨慎，有时候程序员会通过 HTTP 状态码来传递信息，如果不小心禁止了会造成不必要的麻烦。
proxy_read_timeout 参数根据业务场景需要进行设定，不宜过长，也不宜过短。
标签：必须 fastcgi air 就是 备份 read ip地址 业务 local
原文地址：https://www.cnblogs.com/hukey/p/10534021.html
