【NGINX入门】8.Nginx的upstream 模块及参数测试

Posted 2023-03-09

参考技术A

本文介绍nginx的upstream模块的指令和参数说明。

2.1 配置示例

语法：upstream name …
默认值：none
使用环境：http
功能：该指令是一个组合型指令它描述了一组服务器，这组服务器将会被指令 proxy_pass 和 fastcgi_pass 作为一个单独的实体使用，它们可以将 server 监听在不同的端口，而且还可以同时使用TCP和UNIX套接字监听。服务器可以设置不同的权重，如果没有设置权重，那么默认会将其设置为 1 。

语法：ip_hash
默认值：none
使用环境：upstream
功能：如果使用了该指令，那么将会导致客户端的请求以用户端IP地址分布在 upstream 中的 server 之间。它的关键技术在于对这个请求客户端IP地址进行哈希计算，这种方法保证了客户端请求总是能够传递到同一台后台服务器，但是如果该服务器被认定为无效，那么这个客户端的请求将会被传递到其他服务器，因此，这种机制是一个高概率将客户端请求总是连接到同一台服务器。

Nginx 的 upstream 支持 5 种分配方式，其中有三种为 Nginx 原生支持的分配方式，后两种为第三方支持的分配方式。

语法：server name [parameters]
默认值：none
使用环境：upstream
功能：该指令用于设置服务器的 name，对于 name，可以使用域名、ip地址、端口或是 UNIX 套接字，如果一个域名被解析到多个 IP 地址，那么所有的 IP 地址都将会被使用。
可选的 parameters 如下：

功能：该变量表示了处理该请求的 upstream 中 server 的地址

功能：该变量出现在 Nginx 0.8.3 版本中， 可能的值如下：

功能：该变量为 upstream 中 server 的响应状态

功能：upstream server 响应的时间，单位为秒，能够精准到毫秒。如果有多个 server 响应回答，那么会用逗号和冒号分隔开

功能：HTTP 协议头。例如：$upstream_http_host

参数相关说明介绍完毕，接下来重点测试部分参数：

1台反向代理（nginx/1.14.2）
2台后端web（apache+php）

首先，查看客户端 发起一次 连接请求的过程：

通过抓包，可以看到 浏览器 请求一次 nginx 反向代理：

3.1 max_fails 和 fail_timeout

fail_timeout - 出错后，暂停server的时间。</pre>

配置如下图：

主机信息：
（1）当 max_fails 为 0 ， fail_timeout 为 0

通过浏览器快速刷新4次，分析如下：

一共发起了 4 次连接请求，根据 upstream默认轮询方式，有两次都轮询到了 192.168.118.17 （服务关闭）上。

一共发起了 4 次请求，而 web1 接收到了 4 次，也就是这 4 次请求，都是 web1 来响应的。

通过上图，当 nginx 首次轮询到 web2 时，连接失败，web2 返回 RST，nginx会再次发起请求到 web1 。

总结：
（1）max_fails = 0 and fail_timeout = 0 时，后端服务故障时，依然会轮询到故障主机，且没有暂停服务时间的限制。

（2） max_fails = 0 and fail_timeout = 5

通过浏览器快速刷新，分析如下：

通过错误日志可以看出，当 upstream 没有设置 最大错误数（max_fails），无论后端server是否有效，都会轮询到该server上，fail_timeout 设置任何值都是无效的。

（3） max_fails = 3 and fail_timeout = 5

通过浏览器快速刷新，分析如下：

通过配置最大失败连接数为 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

运用场景：
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关掉即可

案例分析（nginx proxy_next_upstream导致的一个重复提交错误）：
一个请求被重复提交，原因是nginx代理后面挂着2个服务器，请求超时的时候（其实已经处理了），结果nigix发现超时，有把请求转给另外台服务器又做了次处理。

解决办法：

语法:

默认值: proxy_next_upstream error timeout;
上下文: http, server, location

upstream 默认后端server失效标准： timeout 和 Connect refuse，在这里例子中，使用

三次都是返回 200 状态，说明 proxy_next_upstream 已经将后端server 返回 500 状态的主机拦截为失效。

proxy_connect_timeout : 后端服务器连接的超时时间 发起握手等候响应超时时间
proxy_read_timeout: 连接成功后，等候后端服务器响应时间 其实已经进入后端的排队之中等候处理（也可以说是后端服务器处理请求的时间）
proxy_send_timeout : 后端服务器数据回传时间_就是在规定时间之内后端服务器必须传完所有的数据

这里对 proxy_read_timeout 进行测试：

测试结果：

三次返回结果一致，每次请求均耗时 2秒，这是因为 proxy_read_timeout 设置为 2s ，而后端的程序: web1-sleep 3 、web2-sleep 5，都无法及时响应。

修改 proxy_read_time 为 3 秒，测试如下：

当轮询到 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 参数根据业务场景需要进行设定，不宜过长，也不宜过短。

（1）Nginx - upstream 模块及参数测试[参数解析很详细] https://www.cnblogs.com/hukey/p/10534021.html

（2）upstream模块官网
http://nginx.org/en/docs/http/ngx_http_upstream_module.html