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

「爱情、让人受尽委屈。」 2021-11-16 16:04 1874阅读 0赞

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

## 前言 ##

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

## 代理多台服务器 ##

先来看一个简单的版本：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70][]

指令： upstream
    语法： upstream name {...}
    环境： http含义：定义一组 HTTP服务器，这些服务器可以监听不同的端口，以及 TCP和 UNIX套接字。在同一个 upstream中可以混合使用不同的端口、 TCP和 UNIX套接字。
    
    
    指令： server
    语法： server address [parameters];
    环境： upstream
    含义：配置后端服务器，参数可以是不同的 IP地址、端口号，甚至域名。

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 1][]  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 2][]

## 故障转移 ##

如果在前面的配置示例中出现了超过请求失败次数的服务器，下面这些参数可以用来对这些服务器进行配置： 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的配置环境内设置（默认根据权重轮询）。

负载均衡指令见下表：  
![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 3][]

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

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 4][]

**注意：**

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

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

## 利用长连接提升性能 ##

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 5][]  
![20190728234357268.jpg][]  
长连接配置指令说明见下表：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 6][]

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

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

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

![20190728234604928.jpg][]

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

resolver指令说明见下表。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 8][]

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70]: /images/20211116/f545153781c74ee08f6e47204a4e1cb9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 1]: /images/20211116/b34f31f4f73e499dabee4e8220060162.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 2]: /images/20211116/f52fc71ff60a4ad5914c957e09e3d0b6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 3]: /images/20211116/6a8f6779f7954bb980113fd41de3b412.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 4]: /images/20211116/45b94680e356426d8696607a4a927312.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 5]: /images/20211116/5c5e8c3216d9453babeb6909a08ad297.png
[20190728234357268.jpg]: /images/20211116/35dc5acc757f43658021549ef0d5ab68.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 6]: /images/20211116/ff9f263146cf4b54ab9c278b481c8711.png
[20190728234604928.jpg]: /images/20211116/16b00f09aff84d5dbe3ec28081ac251b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 7]: /images/20211116/6915352b75734aeeb8f1b9a2445c9386.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0xMODQ1ODc2NDI1_size_16_color_FFFFFF_t_70 8]: /images/20211116/97cb62524d934766a0ef42b4d8e1751d.png