Nginx失败重试中的HTTP协议幂等问题: non_idempotent

共计 3021 个字符，预计需要花费 8 分钟才能阅读完成。

Nginx 通过反向代理做负载均衡时，如果被代理的其中一个服务发生错误或者超时的时候，通常希望 Nginx 自动重试其他的服务，从而实现服务的高可用性。实际上 Nginx 本身默认会有错误重试机制，并且可以通过 proxy_next_upstream 来自定义配置。

如果不了解 HTTP 协议以及 Nginx 的机制，就可能在使用过程中遇到各种各样的坑。例如服务出现了错误或超时却未重试，或者一些例如创建订单或发送短信这类的 HTTP 接口，客户端只发送一次请求，后台却由于 Nginx 重试导致创建了多个订单，或者收到多条短信，导致一些业务上的问题。

在 Nginx 配置文件中，proxy_next_upstream用于指定在什么情况下 Nginx 会将请求转移到其他服务器上。其默认值是proxy_next_upstream error timeout，即发生网络错误以及超时，才会重试其他服务器。默认情况下服务返回 500 状态码是不会重试的，如果想在响应 500 状态码时也进行重试，可以配置：

proxy_next_upstream error timeout http_500;

当然还有 http_502、http_503、http_404 等可以指定在出现哪些状态码的情况下需要重试。具体配置项可以参考官方文档: http://nginx.org/en/docs/http…。

用一个最简单的例子来测试一下该特性，例如下面是 Spring Boot 写了一个简单的 HTTP 接口，返回 500 状态码：

@SpringBootApplication
public class NginxRetryApplication {public static void main(String[] args) {SpringApplication.run(NginxRetryApplication.class, args);
    }
}

@RestController
class TestController {@RequestMapping("/")
    public String test() {System.out.println("收到一个请求"); // 打印日志
        throw new RuntimeException(); // 抛出异常, 返回 500 状态码}
}

分别使用 9030 和 9031 两个端口号启动该 Spring Boot 服务，然后 Nginx 配置好负载均衡：

upstream nginxretry {
    server 127.0.0.1:9030 max_fails=0;
    server 127.0.0.1:9031 max_fails=0;
}
server {
    listen 9039;
    location / {
        proxy_pass http://nginxretry;
        proxy_next_upstream error timeout http_500;
    }
}

注意：以上配置中 max_fails=0 是为了更方便的测试 Nginx 错误重试机制。max_fails默认值是 1，用于指定一个 server 在一段时间内（默认 10s）发生错误次数达到多少次，Nginx 就会自动将该服务器下线。这里设置为 0 是禁用这个特性，防止在测试过程中服务器被踢下线不好测试。线上环境下一般不会设置max_fails=0。

配置完成后重启 Nginx，使用 GET 方式请求 http://localhost:9039/，再分别查看 9030 和 9031 两个端口号对应的服务日志，可以发现两个服务都收到请求，也就是 Nginx 在访问其中一个服务收到 500 错误状态码后，又尝试去访问另一个服务。

再次使用 POST 方式请求 http://localhost:9039/，再分别查看 9030 和 9031 两个端口号对应的服务日志，可以发现只有一个服务收到请求。也就是 当请求类型是 POST 时，Nginx 默认不会失败重试。如果想让 POST 请求也会失败重试，可以继续向下阅读。

在 Nginx 文档中可以看到 proxy_next_upstream 有一个选项non_idempotent:

normally, requests with a non-idempotent method (POST, LOCK, PATCH) are not passed to the next server if a request has been sent to an upstream server (1.9.13); enabling this option explicitly allows retrying such requests;

通常情况下，如果请求使用非等幂方法（POST、LOCK、PATCH），请求失败后不会再到其他服务器进行重试。加上 non_idempotent 选项后，即使是非幂等请求类型（例如 POST 请求），发生错误后也会重试。

如果想让 POST 请求也会失败重试，需要配置non_idempotent：

upstream nginxretry {
    server 127.0.0.1:9030 max_fails=0;
    server 127.0.0.1:9031 max_fails=0;
}
server {
    listen 9039;
    location / {
        proxy_pass http://nginxretry;
        proxy_next_upstream error timeout http_500 non_idempotent;
    }
}

重启 Nginx 后再次使用 POST 请求访问 http://localhost:9039/，再分别查看 9030 和 9031 两个端口号对应的服务日志，可以看到两个服务都收到请求，也就是 POST 请求也会重试了。不过实际上在生产环境中，不建议加上 non_idempotent 选项，具体原因可以继续往下阅读。

在 HTTP 协议规范中，对幂等方法（Idempotent Method）做了以下定义：

A request method is considered “idempotent” if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.

如果使用该方法的多个相同请求对服务器的预期效果与单个请求的效果相同，则认为请求方法是幂等的。常见的 HTTP 请求方法中，GET 是幂等的，而 POST 是非幂等的。如果在回答面试题 ”GET 和 POST 区别 ” 时能答出这一点，才能说明对 HTTP 协议有一定的理解。

在做业务开发是如何理解幂等性，举个最简单的例子：GET 方法一般用于获取数据，如果获取的是数据库数据，对应的是 SELECT 语句。同样的 SELECT 语句执行一次还是多次，都不会影响数据。而 POST 一般对应 INSERT，如果执行多次后，可能会造成数据重复插入的问题。所以不要使用 GET 方法做一些 INSERT 操作，在业务开发时要遵循 HTTP 协议规范。

生产环境中为什么不建议加上 non_idempotent 选项？因为无论是发生 500 错误还是 timeout，服务器上的业务可能都已经执行过了，而重试会导致非幂等方法重复执行，从而导致业务问题，例如一个请求会创建了多个订单，或者收到多条短信的问题。

http://nginx.org/en/docs/http…
https://tools.ietf.org/html/r…

proxy_next_upstream

non_idempotent

什么是幂等方法

参考文档

关注我

Just My Socks（注册教程内含优惠码）