在文章中，作者首先解释了Nginx的架构和专有术语，然后介绍了安装和配置的实践经验。Web服务器被描述为一个中间人，负责将客户端请求指向后端服务器并返回响应。文章详细解释了代理和反向代理的概念，以及负载均衡的作用。负载均衡被解释为反向代理的一个实例，通过均匀分配请求来提高服务器性能。

作者还讨论了有状态和无状态应用的区别。有状态应用存储特定信息，可能导致客户端交互时出现问题；而无状态应用避免了这些问题，但可能需要更多的数据库API调用。

最后，作者介绍了Nginx，将其比喻为一个网络服务器，能够基于算法向后端服务器发送请求并返回数据给客户端。通过示意图和实例，读者能更好地理解Nginx在整个网络通信过程中的作用。

---

小白入门学习 Nginx 代理服务器需要注意什么？

学习 Nginx 代理服务器需要注意以下几点：1. 了解 Nginx 的基本概念和原理，例如反向代理、负载均衡等。 2. 学习 Nginx 的安装和配置方法，包括如何启动、停止、重启 Nginx，以及如何配置 Nginx。 3. 学习 Nginx 的常用功能和指令，例如 location、proxy_pass、rewrite 等。 4. 学习 Nginx 的日志记录和监控方法，例如如何查看访问日志、错误日志等。

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

本文介绍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的时间。

配置如下图：

主机信息： （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 模块及参数测试[参数解析很详细]

（2）upstream模块官网

Nginx的安装目录详解

在上一节我们安装了nginx，但是具体安装位置在哪我们如何查看呢？每个文件的作用是什么呢？编译参数是哪些呢？基本配置语法有哪些呢？下面，我们一起学习吧！ 一：安装目录详解 首先我们查看一下安装nginx之后总共生成了哪些文件 在上面的文件中包括配置文件和日志文件，下面我们看看主要文件含义。 /etc/nginx/ 是主配置文件，当Nginx启动优先读取，当没有变更的时候，会读取/etc/nginx/conf.d/（安装是默认加载的）。 当Nginx要处理一些不能识别的扩展名和文件类型的时候就需要编辑该文件 Nginx处理可以做代理，还可以做缓存服务

标签： 服务器、 Web、 服务器、 Nginx、

本文地址： https://yihaiquanyi.com/article/43d9c70f1902e0b28eca.html

上一篇：物理阉割美国一男子强奸14岁少女遭重刑被判...
下一篇：赚钱新机遇专业团队助你由零开始最新赚钱机...