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

Nginx经过反向代理作负载均衡时，若是被代理的其中一个服务发生错误或者超时的时候，一般但愿Nginx自动重试其余的服务，从而实现服务的高可用性。实际上Nginx自己默认会有错误重试机制，而且能够经过proxy_next_upstream来自定义配置。

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

proxy_next_upstream

在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请求也会失败重试，能够继续向下阅读。

non_idempotent

在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...

关注我