作者：叄滴水
部落格：https://blog.csdn.net/qq_30285985/

前言

在訂單的狀態發生改變後，支付寶會通過非同步方式同志商家伺服器。商家伺服器需要返回success這7個字元，如果不是，則會不斷重複傳送。

微信也是如此，必須需要商家伺服器的正確反饋。既然這樣，在回撥介面就需要進行冪等處理。

一、什麼是冪等？

冪等操作的特點是其任意多次執行所產生的影響均與一次執行的影響相同。

細想一下回調介面一般會這樣處理：

1. 檢視訂單是否存在。
2. 修改訂單狀態。
3. 如果是支付成功狀態，則進行發貨。

這種邏輯本身是沒有什麼問題的，但是它不是一個冪等介面，如果收到好幾次訂單1001支付成功的請求，則會對訂單1001

因此，我們需要對此介面做一個處理，使得即使有很多請求都告訴商戶伺服器訂單1001支付成功的請求，商戶也只發貨一次。

二、如何進行冪等處理

對於這種介面的冪等處理，我也是思量許久，最終決定再生使用修改狀態的方式。

具體實現方式如下：

1. 訂單表t_order存在訂單號1001的訂單是未支付狀態。
2. 支付寶轉賬成功，告訴商家伺服器訂單1001的訂單轉賬成功。
3. 商家伺服器驗籤。
4. 檢視訂單是否存在，基本資訊是否一致。
5. 修改此訂單狀態。通過update t_order set 狀態=已支付 where order_id=1001 and 狀態=未支付
6. 通過如上sql樂觀鎖的思想對發貨進行控制，只有sql執行的時候有修改成功，則進行發貨，修改失敗則不發貨。

通過樂觀鎖可以有效的控制發貨次數。不管幾次回撥通知，只有當前訂單是未支付狀態並且成功修改成已支付狀態之後才進行發貨。

如下圖，兩個sql一起執行修改訂單狀態，但是肯定只會有一個sql修改成功。

修改成功的執行緒進行發貨即可。

如果思路有什麼缺點，或者您還有更好的實現方式，請留言點評。

最後，關注公眾號Java技術棧，在後臺回覆：面試，可以獲取我整理的 Java 系列面試題和答案，非常齊全。

本文來自作者「叄滴水」投稿，謝謝分享，也歡迎愛好技術分享的各位技術朋友向「Java技術棧」投稿，讓更多人看到，投稿方式：關注公眾號「Java技術棧」在後臺回覆：投稿。

近期熱文推薦：

1.1,000+ 道 Java面試題及答案整理(2021最新版)

2.終於靠開源專案弄到 IntelliJ IDEA 啟用碼了，真香！

3.阿里 Mock 工具正式開源，幹掉市面上所有 Mock 工具！

4.Spring Cloud 2020.0.0 正式釋出，全新顛覆性版本！

5.《Java開發手冊（嵩山版）》最新發布，速速下載！

覺得不錯，別忘了隨手點贊+轉發哦！