摘要：再次使用方式請(qǐng)求，再分別查看和兩個(gè)端口號(hào)對(duì)應(yīng)的服務(wù)日志，可以發(fā)現(xiàn)只有一個(gè)服務(wù)收到請(qǐng)求。常見的請(qǐng)求方法中，是冪等的，而是非冪等的。而一般對(duì)應(yīng)，如果執(zhí)行多次后，可能會(huì)造成數(shù)據(jù)重復(fù)插入的問題。

Nginx通過反向代理做負(fù)載均衡時(shí)，如果被代理的其中一個(gè)服務(wù)發(fā)生錯(cuò)誤或者超時(shí)的時(shí)候，通常希望Nginx自動(dòng)重試其他的服務(wù)，從而實(shí)現(xiàn)服務(wù)的高可用性。實(shí)際上Nginx本身默認(rèn)會(huì)有錯(cuò)誤重試機(jī)制，并且可以通過proxy_next_upstream來自定義配置。

如果不了解HTTP協(xié)議以及Nginx的機(jī)制，就可能在使用過程中遇到各種各樣的坑。例如服務(wù)出現(xiàn)了錯(cuò)誤或超時(shí)卻未重試，或者一些例如創(chuàng)建訂單或發(fā)送短信這類的HTTP接口，客戶端只發(fā)送一次請(qǐng)求，后臺(tái)卻由于Nginx重試導(dǎo)致創(chuàng)建了多個(gè)訂單，或者收到多條短信，導(dǎo)致一些業(yè)務(wù)上的問題。

在Nginx配置文件中，proxy_next_upstream用于指定在什么情況下Nginx會(huì)將請(qǐng)求轉(zhuǎn)移到其他服務(wù)器上。其默認(rèn)值是proxy_next_upstream error timeout，即發(fā)生網(wǎng)絡(luò)錯(cuò)誤以及超時(shí)，才會(huì)重試其他服務(wù)器。默認(rèn)情況下服務(wù)返回500狀態(tài)碼是不會(huì)重試的，如果想在響應(yīng)500狀態(tài)碼時(shí)也進(jìn)行重試，可以配置：

proxy_next_upstream error timeout http_500;

當(dāng)然還有http_502、http_503、http_404等可以指定在出現(xiàn)哪些狀態(tài)碼的情況下需要重試。具體配置項(xiàng)可以參考官方文檔: http://nginx.org/en/docs/http... 。

用一個(gè)最簡單的例子來測(cè)試一下該特性，例如下面是Spring Boot寫了一個(gè)簡單的HTTP接口，返回500狀態(tài)碼：

@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("收到一個(gè)請(qǐng)求"); // 打印日志
        throw new RuntimeException(); // 拋出異常, 返回500狀態(tài)碼
    }
}

分別使用9030和9031兩個(gè)端口號(hào)啟動(dòng)該Spring Boot服務(wù)，然后Nginx配置好負(fù)載均衡：

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是為了更方便的測(cè)試Nginx錯(cuò)誤重試機(jī)制。max_fails默認(rèn)值是1，用于指定一個(gè)server在一段時(shí)間內(nèi)（默認(rèn)10s）發(fā)生錯(cuò)誤次數(shù)達(dá)到多少次，Nginx就會(huì)自動(dòng)將該服務(wù)器下線。這里設(shè)置為0是禁用這個(gè)特性，防止在測(cè)試過程中服務(wù)器被踢下線不好測(cè)試。線上環(huán)境下一般不會(huì)設(shè)置max_fails=0。

配置完成后重啟Nginx，使用GET方式請(qǐng)求 http://localhost:9039/ ，再分別查看9030和9031兩個(gè)端口號(hào)對(duì)應(yīng)的服務(wù)日志，可以發(fā)現(xiàn)兩個(gè)服務(wù)都收到請(qǐng)求，也就是Nginx在訪問其中一個(gè)服務(wù)收到500錯(cuò)誤狀態(tài)碼后，又嘗試去訪問另一個(gè)服務(wù)。

再次使用POST方式請(qǐng)求 http://localhost:9039/ ，再分別查看9030和9031兩個(gè)端口號(hào)對(duì)應(yīng)的服務(wù)日志，可以發(fā)現(xiàn)只有一個(gè)服務(wù)收到請(qǐng)求。也就是當(dāng)請(qǐng)求類型是POST時(shí)，Nginx默認(rèn)不會(huì)失敗重試。如果想讓POST請(qǐng)求也會(huì)失敗重試，可以繼續(xù)向下閱讀。

在Nginx文檔中可以看到proxy_next_upstream有一個(gè)選項(xiàng)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;

通常情況下，如果請(qǐng)求使用非等冪方法（POST、LOCK、PATCH），請(qǐng)求失敗后不會(huì)再到其他服務(wù)器進(jìn)行重試。加上non_idempotent選項(xiàng)后，即使是非冪等請(qǐng)求類型（例如POST請(qǐng)求），發(fā)生錯(cuò)誤后也會(huì)重試。

如果想讓POST請(qǐng)求也會(huì)失敗重試，需要配置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請(qǐng)求訪問 http://localhost:9039/ ，再分別查看9030和9031兩個(gè)端口號(hào)對(duì)應(yīng)的服務(wù)日志，可以看到兩個(gè)服務(wù)都收到請(qǐng)求，也就是POST請(qǐng)求也會(huì)重試了。不過實(shí)際上在生產(chǎn)環(huán)境中，不建議加上non_idempotent選項(xiàng)，具體原因可以繼續(xù)往下閱讀。

在HTTP協(xié)議規(guī)范中，對(duì)冪等方法（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.

如果使用該方法的多個(gè)相同請(qǐng)求對(duì)服務(wù)器的預(yù)期效果與單個(gè)請(qǐng)求的效果相同，則認(rèn)為請(qǐng)求方法是冪等的。常見的HTTP請(qǐng)求方法中，GET是冪等的，而POST是非冪等的。如果在回答面試題"GET和POST區(qū)別"時(shí)能答出這一點(diǎn)，才能說明對(duì)HTTP協(xié)議有一定的理解。

在做業(yè)務(wù)開發(fā)是如何理解冪等性，舉個(gè)最簡單的例子：GET方法一般用于獲取數(shù)據(jù)，如果獲取的是數(shù)據(jù)庫數(shù)據(jù)，對(duì)應(yīng)的是SELECT語句。同樣的SELECT語句執(zhí)行一次還是多次，都不會(huì)影響數(shù)據(jù)。而POST一般對(duì)應(yīng)INSERT，如果執(zhí)行多次后，可能會(huì)造成數(shù)據(jù)重復(fù)插入的問題。所以不要使用GET方法做一些INSERT操作，在業(yè)務(wù)開發(fā)時(shí)要遵循HTTP協(xié)議規(guī)范。

生產(chǎn)環(huán)境中為什么不建議加上non_idempotent選項(xiàng)？因?yàn)闊o論是發(fā)生500錯(cuò)誤還是timeout，服務(wù)器上的業(yè)務(wù)可能都已經(jīng)執(zhí)行過了，而重試會(huì)導(dǎo)致非冪等方法重復(fù)執(zhí)行，從而導(dǎo)致業(yè)務(wù)問題，例如一個(gè)請(qǐng)求會(huì)創(chuàng)建了多個(gè)訂單，或者收到多條短信的問題。

http://nginx.org/en/docs/http...

https://tools.ietf.org/html/r...