一、什么是冪等性

所謂冪等，簡單地說，就是對接口的多次調用所產生的結果和調用一次是一致的。

那么我們為什么需要接口具有冪等性呢？設想一下以下情形：

支付接口，重復支付會導致多次扣錢 訂單接口，同一個訂單可能會多次創建。

在接收消息的時候，消息推送重復。如果處理消息的接口無法保證冪等，那么重復消費消息產生的影響可能會非常大。

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

二、冪等性的解決方案

1）唯一索引

使用唯一索引可以避免臟數據的添加，當插入重復數據時數據庫會拋異常，保證了數據的唯一性。

2）樂觀鎖

這里的樂觀鎖指的是用樂觀鎖的原理去實現，為數據字段增加一個version字段，當數據需要更新時，先去數據庫里獲取此時的version版本號

select?version?from?tablename?where?xxx

更新數據時首先和版本號作對比，如果不相等說明已經有其他的請求去更新數據了，提示更新失敗。

update?tablename?set?count=count+1,version=version+1?where?version=#{version}

3）悲觀鎖

樂觀鎖可以實現的往往用悲觀鎖也能實現，在獲取數據時進行加鎖，當同時有多個重復請求時其他請求都無法進行操作

4）分布式鎖

冪等的本質是分布式鎖的問題，分布式鎖正常可以通過redis或zookeeper實現；在分布式環境下，鎖定全局唯一資源，使請求串行化，實際表現為互斥鎖，防止重復，解決冪等。

目前主要有三種方式實現redis的分布式鎖：

setNx 命令

set 命令

Redission 框架

具體流程圖如下：

具體步驟：

用戶通過瀏覽器發起請求，服務端會收集數據，并且生成訂單號 code 作為唯一業務字段。

使用 redis 的 set 命令，將該訂單 code 設置到 redis 中，同時設置超時時間。

判斷是否設置成功，如果設置成功，說明是第一次請求，則進行數據操作。

如果設置失敗，說明是重復請求，則直接返回成功。

需要特別注意的是：分布式鎖一定要設置一個合理的過期時間，如果設置過短，無法有效的防止重復請求。如果設置過長，可能會浪費redis的存儲空間，需要根據實際業務情況而定。

5）token機制

token 機制的核心思想是為每一次操作生成一個唯一性的憑證，也就是 token。一個 token 在操作的每一個階段只有一次執行權，一旦執行成功則保存執行結果。對重復的請求，返回同一個結果。token 機制的應用十分廣泛。

該方案跟之前的所有方案都有點不一樣，需要兩次請求才能完成一次業務操作。

第一次請求獲取token

第二次請求帶著這個token，完成業務操作。

具體流程圖如下：

第一步，先獲取token。

第二步，做具體業務操作。

具體步驟：

用戶訪問頁面時，瀏覽器自動發起獲取token請求。

服務端生成token，保存到redis中，然后返回給瀏覽器。

用戶通過瀏覽器發起請求時，攜帶該token。

在redis中查詢該token是否存在，如果不存在，說明是第一次請求，做則后續的數據操作。

如果存在，說明是重復請求，則直接返回成功。

在redis中token會在過期時間之后，被自動刪除。

以上方案是針對冪等設計的。

如果是防重設計，流程圖要改改：

需要特別注意的是：token必須是全局唯一的。

編輯：黃飛

?