一、什么是冪等性

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

那么我們?yōu)槭裁葱枰涌诰哂袃绲刃阅?？設想一下以下情形：

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

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

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

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

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

二、冪等性的解決方案

1）唯一索引

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

2）樂觀鎖

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

select?version?from?tablename?where?xxx

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

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

3）悲觀鎖

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

4）分布式鎖

冪等的本質是分布式鎖的問題，分布式鎖正?？梢酝ㄟ^redis或zookeeper實現(xiàn)；在分布式環(huán)境下，鎖定全局唯一資源，使請求串行化，實際表現(xiàn)為互斥鎖，防止重復，解決冪等。

目前主要有三種方式實現(xiàn)redis的分布式鎖：

setNx 命令

set 命令

Redission 框架

具體流程圖如下：

具體步驟：

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

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

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

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

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

5）token機制

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

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

第一次請求獲取token

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

具體流程圖如下：

第一步，先獲取token。

第二步，做具體業(yè)務操作。

具體步驟：

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

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

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

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

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

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

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

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

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

編輯：黃飛

?