Nginx常见基本配置---upstream 使用指南

Nginx常见基本配置—upstream 使用指南

前言

利用 proxy_ pass可以将请求代理到后端服务器，前一篇博客中的的配置示例都指向同一台服务器，如果需要指向多台服务器就要用到 ngx_ http_ upstream_ module。它为反向代理提供了负载均衡及故障转移等重要功能。

代理多台服务器

先来看一个简单的版本：

指令： upstream
语法： upstream name {...}
环境： http含义：定义一组 HTTP服务器，这些服务器可以监听不同的端口，以及 TCP和 UNIX套接字。在同一个 upstream中可以混合使用不同的端口、 TCP和 UNIX套接字。


指令： server
语法： server address [parameters];
环境： upstream
含义：配置后端服务器，参数可以是不同的 IP地址、端口号，甚至域名。 

server指令拥有丰富的参数，其参数说明见下表：

故障转移

如果在前面的配置示例中出现了超过请求失败次数的服务器，下面这些参数可以用来对这些服务器进行配置： proxy_ next_ upstream、 fastcgi_ next_ upstream、 uwsgi_ next_ upstream、 scgi_ next_ upstream、 memcached_ next_ upstream和 grpc_ next_ upstream。

下面用最常见的 proxy_ next_ upstream为例进行说明。

指令： proxy_ next_ upstream
语法： proxy_ next_ upstream error | timeout | invalid_ header | http_ 500 | http_ 502 | http_ 503 | http_ 504 | http_ 403 | http_ 404 | http_ 429 | non_ idempotent | off ...;
默认值： proxy_ next_ upstream error timeout;
环境： http、 server、 location
含义：定义转发条件，当请求返回 Nginx时，如果 HTTP状态满足 proxy_ next_ upstream设置的条件，就会触发 Nginx将请求重新转发到下一台后端服务器，并累加出现此状态的服务器的失败次数（当超过 max_ fails和 fail_ timeout的值时就会设置此服务器为不可用）。如果设置为 off，则表示关闭此功能。

指令： proxy_ next_ upstream_ tries
语法： proxy_ next_ upstream_ tries number;
默认值： proxy_ next_ upstream_ tries 0;
环境： http、 server、 location
含义：定义尝试请求的次数，达到次数上限后就停止转发，并将请求内容返回客户端。

指令： proxy_ next_ upstream_ timeout
语法： proxy_ next_ upstream_ timeout time;
默认值： proxy_ next_ upstream_ timeout 0;
环境： http、 server、 location
含义：限制尝试请求的超时时间，如果第一次请求失败，下一次请求就会被此参数值控制。若设置为 0，则表示无超时时间，但尝试的请求仍会受到 proxy_ read_ timeout、 proxy_ send_ timeout、 proxy_ connect_ timeout的影响。

注意：通过这些配置，可以在后端服务器的某些节点出现请求异常时，快速做出故障切换的操作，从而屏蔽这些异常的请求。但是这存在一种隐患，即如果 proxy_ next_ upstream_ tries设置的值比较大，且 proxy_ next_ upstream也设置了很多状态，当发生大面积异常时，重试不断累加，可能会导致请求反复向多个服务器发送，这样会给后端服务器带来更大的压力。

负载均衡

Nginx不仅支持代理多台后端服务器，也支持各种负载均衡模式，负载均衡在 upstream的配置环境内设置（默认根据权重轮询）。

负载均衡指令见下表：

通过 hash分片提升缓存命中率

缓存系统是减少后端服务压力的重要组件，常见的 HTTP缓存系统有 Nginx的 proxy_ cache、 varnish、 squid。如果通过反向代理去获取缓存数据，一般需要使用 hash分片，以避免 URL的请求随机进入缓存系统的某个分片，导致缓存命中率低、后端服务器压力上升。

基于 URL缓存的服务配置一般如下所示，相同的 URL（包含参数）会进入相同的后端缓存系统。

注意：

• 增减节点会导致 hash重新计算，因此增减节点最好选择在服务的低峰期进行。
• 在缓存系统上使用 max_ fails不一定是最好的选择，但一旦使用请确保 proxy_ next_ upstream的合理性，尽量不要配置各种 HTTP状态码，因为缓存系统代理的是后端服务，当后端服务异常时会将错误的状态码返回给 Nginx，这样会让 Nginx以为缓存系统出了问题，从而将缓存节点当作失败的节点，停止分流。

缓存系统的故障转移应该只以存活检查方式（一般指检查缓存系统的端口是否存活，以及固定检查一个接口是否能返回正常的响应）为主。可以结合健康检测功能，或者动态剔除异常缓存节点的功能来使用，详细介绍请看后续。

利用长连接提升性能

在 Nginx中，使用 upstream进行后端访问默认用的是短连接，但这会增加网络资源的消耗。可以通过配置长连接，来减少因建立连接产生的开销、提升性能。和长连接有关的配置示例如下：

长连接配置指令说明见下表：

注意：如果没有添加长连接，在压力测试（以下简称压测）环境中，可能会出现这样的情景：当压测达到一定的 QPS（ Query Per Second，每秒查询率）后， Nginx服务器突然“卡死”， QPS直接降到几乎为 0，但是压测并没有停；几分钟后又会自动恢复，然后再压测一段时间后， QPS又会突然降到接近于 0。这种情况就要考虑是不是 timewait的状态过多了。

利用 resolver加速对内部域名的访问

proxy_ pass可以直接将域名代理到后端服务器上，请求前会先解析出 IP地址，例如：

反复的 DNS（ Domain Name System，域名系统）解析会影响请求的速度，并且如果出现连接 DNS服务器超时的情况，可能会导致请求无法发送，这里需要用 DNS缓存来解决这个问题，示例代码如下：

resolver指令说明见下表。

注意：解析 DNS后，通过 set $ upstream_ host test2. zhe800. com的方式，将获取的 IP地址再赋值给 proxy_ pass，这是为了让 Nginx重新去解析 DNS中的 IP地址。利用 valid的配置，可以减少 DNS的解析次数，从而提高请求的效率。当然对 DNS缓存时间的控制也要有度，避免出现 DNS切换 IP地址后， Nginx无法快速切换到新 IP地址的情况。如果需要在 upstream内部对域名的配置进行解析，使用 Nginx的开源版会受到一些限制，因为此功能被放到了商业版中，需要和 zone的功能配合使用。