IDC资讯

质量为本、客户为根、勇于拼搏、务实创新

< 返回IDC资讯列表

Nginx负载均衡配置有哪些误区

发布时间:2022-10-10

Nginx负载均衡配置的误区有:1、Nginx记录了连接上游失败,这个请求就返回错误请求,这个说法是错误的;2、max_fails是指连续请求失败的次数,这个也是错误的;3、fail_timeout越短越好和fail_timeout越长越好,这两种做法也是不对的。


下面是详细介绍:

Nginx 的 upstream 模块中 max_fails 及 fail_timeout,这两个指令,分别是配置关于负载均衡过程中,对于上游(后端)服务器的失败尝试次数和不可用时间,很多人不是很理解这两个参数到底怎么用及具体的含义。

先看官网文档中的描述

官网文档中解释 max_fails 是指在 fail_timeout 配置的时间内,服务器通信失败的次数,默认为1,即在 fail_timeout 时间内,1次请求失败即不再尝试,将请求根据 hash 规则,转发到下一个上游服务

fail_timeout 有两种含义:

  • 当已经确认上游服务不可用时,是指与上游服务器通信失败次数的时间

  • 服务器不可用的时间段

默认是10s

文字不是很好理解,搭建个实验环境,环境如下:

  • Nginx

  • PHP-FPM(x2)

nginx 通过 fast-cgi 将 php 请求转发到 PHP-FPM,这里 PHP-FPM 服务即上游服务,设置 upstream,负载 PHP-FPM

upstream 按照默认配置,即 max_fails=1,fail_timeout=10

现在通过 tailf 分别监听两个 PHP-FPM 日志

请求4次,因为是默认轮询的,所以可以看时间,轮询将请求分发到两个PHP-FPM上游

可以从上面的日志中看到,按照轮询规则,下次请求应该落到 PHP-FPM2 上面,接着,关掉 PHP-FPM1,继续请求

可以看到,PHP-FPM1肯定是不响应了,PHP-FPM2正常响应,接着看下Nginx日志

可以看到,关掉 PHP-FPM1 后,发起的请求,本来第二次请求(17:49:58)应该分发到 PHP-FPM1 的,然后从 Nginx 错误日志可以看到,连接 PHP-FPM1 失败,这里只做了一次失败尝试,然后 Nginx 将请求转发到 PHP-FPM2 处理了。

接着将 max_fails 设置为2,继续上面的请求

开启 PHP-FPM1,继续请求,两个负载轮询转发请求

接着继续关掉 PHP-FPM1,连续发起多次请求,查看日志

所有请求都在 PHP-FPM2上,看 Nginx 错误日志

两次轮询到PHP-FPM1的时候,失败,之后不会再将请求分发到 PHP-FPM1 上游服务

接着,不开启 PHP-FPM1,继续发起多次请求,由于默认的 fail_timeout=10,所以在上面的失败检测 10s 之后再次发起请求,查看日志

继续分发到 PHP-FPM2,接着看 Nginx 错误日志

可以看到,过了 fail_timeout 的时间后,Ngxin 会再次将请求发往 FPM-PHP1 进行尝试,尝试2次失败后,在 fail_timeout 时间内,不会再将请求分发。

这里有几个误区:

  • Nginx 记录了连接上游失败,这个请求就返回错误请求,或这个请求丢失没处理

这个理解是错误的,Nginx 只是记录了失败的请求到日志,并将这个请求又转发到了可用的其他上游服务,知道所有上游都不可用时,才会返回错误状态。

  • max_fails 是指连续请求失败的次数

max_fails 是在 fail_timeout 指定的时间内的失败次数,请求还是按照配置的负载均衡算法来走,并不是第一次请求失败之后,继续将这个请求在尝试一次,达到失败次数之后,标记为不可用。

  • fail_timeout 越短越好

当访问量大的时候,fail_timeout 设置太短,会导致不断的尝试与不可用上游的连接,耗费大量的 tcp 资源进行连接。

  • fail_timeout 越长越好

当访问量大的时候,fail_timeout设置太长,会导致负载不均衡,有可能会击穿某个上游后端,达不到负载的效果。

TikTok千粉号购买平台:https://tiktokusername.com/