什麼是接口冪等性？爲什麼會產生這個問題？如何保證接口冪等性？

作者：三分惡
原文鏈接：https://cnblogs.com/three-fighter/p/14054749.html

博主負責的項目報了一個問題，用戶操作回退失效。我們的設計裏，操作回退是回到操作前的狀態。經過查看日誌發現，用戶之前的操作做了兩次，也就是說提交操作的接口被調用了兩次，導致之用戶上一次的狀態和這一次的狀態是一樣的，所以操作回退是沒有問題的，問題出在了操作的接口被調用了兩次。

對於防止重複提交，是放在前端控制的，用戶點擊完按鈕之後，後臺返回成功的結果，按鈕就不可見，實踐證明，客戶端的限制操作不是絕對可靠的。

針對上面的場景，就引入了今天的問題，什麼是接口冪等性？如何保證接口冪等性？

什麼是接口冪等性？

首先看看冪等性的概念：

冪等性原本是數學上的概念，用在接口上就可以理解爲：** 同一個接口，多次發出同一個請求，必須保證操作只執行一次。** 調用接口發生異常並且重複嘗試時，總是會造成系統所無法承受的損失，所以必須阻止這種現象的發生。

比如下面這些情況，如果沒有實現接口冪等性會有很嚴重的後果：支付接口，重複支付會導致多次扣錢 ；訂單接口，同一個訂單可能會多次創建。

爲什麼會產生接口冪等性問題？

那麼，什麼情況下，會產生接口冪等性的問題呢？

• 網絡波動, 可能會引起重複請求

• 用戶重複操作, 用戶在操作時候可能會無意觸發多次下單交易, 甚至沒有響應而有意觸發多次交易應用

• 使用了失效或超時重試機制 (Nginx 重試、RPC 重試或業務層重試等)

• 頁面重複刷新

• 使用瀏覽器後退按鈕重複之前的操作, 導致重複提交表單

• 使用瀏覽器歷史記錄重複提交表單

• 瀏覽器重複的 HTTP 請求

• 定時任務重複執行

• 用戶雙擊提交按鈕

如何保證接口冪等性？

那麼最關鍵的來了，如何保證接口冪等性？

解決辦法分爲兩個方向，一個方向是客戶端防止重複調用，一個是服務端進行校驗。當然，客戶端防止重複提交併不是絕對可靠的，優點是實現起來比較簡單。

1. 按鈕只可操作一次

一般是提交後把按鈕置灰或 loding 狀態, 消除用戶因爲重複點擊而產生的重複記錄, 比如添加操作, 由於點擊兩次而產生兩條記錄

2. token 機制

功能上允許重複提交, 但要保證重複提交不產生副作用, 比如點擊 n 次只產生一條記錄, 具體實現就是進入頁面時申請一個 token, 然後後面所有的請求都帶上這個 token, 後端根據 token 來避免重複請求。

3. 使用 Post/Redirect/Get 模式

在提交後執行頁面重定向, 這就是所謂的 Post-Redirect—Get(PRG) 模式, 簡單來說就是當用戶提交連表單後, 跳轉到一個重定向的信息頁面, 這樣就避免用戶按 F5 刷新導致的重複提交, 而且也不會出現瀏覽器表單重複提交的警告, 也能消除按瀏覽器前進和後退導致同樣重複提交的問題。

4. 在 session 存放特殊標誌

在服務端, 生成一個唯一的標識符, 將它存入 session, 同時前端獲取這個標識符的值將它寫入表單的隱藏中, 用於用戶輸入信息後點擊一起提交, 在服務器端, 獲取表單中隱藏字段的值, 與 session 中的唯一標識符比較, 相等說明是首次提交, 就處理本次請求, 然後將 session 中的唯一標識符移除, 不相等則表示是重複提交, 不再做處理。

5. 使用唯一索引防止新增髒數據

利用數據庫唯一索引機制, 當數據重複時, 插入數據庫會拋出異常, 保證不會出現髒數據。

6. 樂觀鎖

如果更新已有數據, 可以進行加鎖更新, 也可以設計表結構時使用樂觀鎖, 通過 version 來做樂觀鎖, 這樣既能保證執行效率, 又能保證冪等, 樂觀鎖的 version 版本在更新業務數據要自增
update table set version = version + 1 where id = #{id} and version = #{version}
示例: 當有重複請求的時候, 第一個請求會獲取當前商品的 version 版本號, 得到的 version 爲 1, 緊接着由於第一個請求還沒更新商品的 version, 第二個請求獲取的 version 依然也是 1, 這時候第一個請求操作更新的時候帶上 version 並作爲條件並且自增更新, 這時候商品的 version 就會變成 2, 當第二個請求去操作更新的時候明顯 version 不一致導致更新失敗。

7. select + insert or update or delete

該方案就是操作之前先查詢一下, 符合要求再插入, 該方案在沒有併發的系統中可以解決冪等問題，在單 JVM 有併發的時候可以用 JVM 加鎖來保證冪等性, 在分佈式環境它是無法保證冪等性, 可以使用分佈式來保證。

8. 分佈式鎖

如果是分佈是系統，構建全局唯一索引比較困難，例如唯一性的字段沒法確定，這時候可以引入分佈式鎖，通過第三方的系統 (redis 或 zookeeper)，在業務系統插入數據或者更新數據，獲取分佈式鎖，然後做操作，之後釋放鎖，這樣其實是把多線程併發的鎖的思路，引入多多個系統，也就是分佈式系統中得解決思路。要點：某個長流程處理過程要求不能併發執行，可以在流程執行之前根據某個標誌(用戶 ID + 後綴等) 獲取分佈式鎖，其他流程執行時獲取鎖就會失敗，也就是同一時間該流程只能有一個能執行成功，執行完成後，釋放分佈式鎖(分佈式鎖要第三方系統提供)。

9. 狀態機冪等

在設計單據相關的業務，或者是任務相關的業務，肯定會涉及到狀態機 (狀態變更圖)，就是業務單據上面有個狀態，狀態在不同的情況下會發生變更，一般情況下存在有限狀態機，這時候，如果狀態機已經處於下一個狀態，這時候來了一個上一個狀態的變更，理論上是不能夠變更的，這樣的話，保證了有限狀態機的冪等。注意：訂單等單據類業務，存在很長的狀態流轉，一定要深刻理解狀態機，對業務系統設計能力提高有很大幫助 。

10. 防重表

以支付爲例: 使用唯一主鍵去做防重表的唯一索引, 比如使用訂單號作爲防重表的唯一索引, 每一次請求都根據訂單號向防重表中插入一條數據, 插入成功說明可以處理後面的業務, 當處理完業務邏輯之後刪除防重表中的訂單號數據, 後續如果有重複請求, 則會因爲防重表唯一索引原因導致插入失敗, 直接返回操作失敗, 直到第一次請求返回結果, 可以看出防重表作用就是加鎖的功能。
注: 最好結合狀態機冪等先判斷一下

11. 緩衝隊列

將請求都快速地接收下來後放入緩衝隊列中, 後續使用異步任務處理隊列中的數據, 過濾掉重複的請求, 該解決方案優點是同步處理改成異步處理、高吞吐量, 缺點則是不能及時地返回請求結果, 需要後續輪詢得處理結果。

12. 全局唯一號

比如通過 source 來源 + 唯一序列號傳入給後端，後端來判斷請求是否重複, 在併發時只能處理一個請求, 其他相同併發請求要麼返回請求重複, 要麼等待 前面請求執行完成後再執行。

參考：

【1】：什麼是接口的冪等性，如何實現接口冪等性？一文搞定
【2】：分佈式系統中接口的冪等性
【3】：高併發下接口冪等性解決方案

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/sMesFvcwYCQhhwW-a-JLUQ