在實際的開發項目中,一個對外暴露的接口往往會面臨很多次請求。這就需要考慮到一個冪等性問題。

冪等性

冪等性的概念是：任意多次執行所產生的影響均與一次執行的影響相同，即無論你請求了多少次，對數據庫的影響都只能有一次，不能重復處理。

所以，按照上面的理解，每次執行的結果都會發生變化，就是非冪等的。如下面三條sql，只有第三條是非冪等的。

SELECT col1 FROM tab1 WHER col2=2，無論執行多少次都不會改變狀態，是天然的冪等。UPDATE tab1 SET col1=1 WHERE col2=2，無論執行成功多少次狀態都是一致的，因此也是冪等操作。UPDATE tab1 SET col1=col1+1 WHERE col2=2，每次執行的結果都會發生變化，這種不是冪等的。

http和冪等性

這里就可以牽扯到http請求了。http請求的get方法是冪等性的，因為不會對數據庫造成更改影響，每次返回的數據都一致。而post請求是非冪等的，因為每請求一次都會添加一條數據

（按restful規范，post常規是添加數據時使用。當然，也有例外，我們有的時候可能需要把查詢方法改造成 POST 方法。比如，超長（1k）的 GET URL 使用 POST 方法來替代，因為 GET 受到 URL 長度的限制。雖然，它不符合冪等性，但是它是一種折中的方案。）

因此 根據restful的規范，http的請求會有以下是否冪等性的判斷。

Http method操作是否冪等

get	獲取數據	√
post	新建數據	×
put	更新所有數據	√
patch	更新部分數據	×
delete	刪除資源	√

為什么要設計冪等性的服務

冪等可以使得客戶端邏輯處理變得簡單，但是卻以服務邏輯變得復雜為代價。滿足冪等服務的需要在邏輯中至少包含兩點：

首先去查詢上一次的執行狀態，如果沒有則認為是第一次請求

在服務改變狀態的業務邏輯前，保證防重復提交的邏輯

冪等的不足

冪等是為了簡化客戶端邏輯處理，卻增加了服務提供者的邏輯和成本，是否有必要，需要根據具體場景具體分析，因此除了業務上的特殊要求外，盡量不提供冪等的接口。

增加了額外控制冪等的業務邏輯，復雜化了業務功能；

把并行執行的功能改為串行執行，降低了執行效率。

冪等性解決方案

防重表
數據庫建立唯一性索引，可以保證最終插入數據庫的只有一條數據（比如訂單表對訂單號進行唯一索引，所有重復提交可能產生同一個訂單號的都會被拆除。當然，訂單號要按你自己的設定走，一般訂單號設計會是時間戳加迭代。那么如果是這樣，創建仍然不能保證冪等，具體根據業務需求來判定建立的唯一索引位置）

token令牌機制，
分為兩個階段，獲取token和使用token。每次接口請求前先獲取一個token，然后再下次請求的時候在請求的header體中加上這個token，后臺進行驗證，如果驗證通過刪除token，下次請求再次判斷token。如果使用上redis緩存，流程圖會是這樣。

先查詢后判斷，
首先通過查詢數據庫是否存在數據，如果存在證明已經請求過了，直接拒絕該請求，如果沒有存在，就證明是第一次進來，直接放行。

支付緩沖區
把訂單的支付請求都快速地接下來，一個快速接單的緩沖管道。后續使用異步任務處理管道中的數據，過濾掉重復的待支付訂單。優點是同步轉異步，高吞吐。不足是不能及時地返回支付結果，需要后續監聽支付結果的異步返回。（一般支付都是采用這種方式）

悲觀鎖或者樂觀鎖。
悲觀鎖可以保證每次for update的時候其他sql無法update數據(在數據庫引擎是innodb的時候,select的條件必須是唯一索引,防止鎖全表)
樂觀鎖，一般通過version來做樂觀鎖，這樣既能保證執行效率，又能保證冪等。例如： UPDATE tab1 SET col1=1,version=version+1 WHERE version=#version# 不過，樂觀鎖存在失效的情況，就是常說的ABA問題，不過如果version版本一直是自增的就不會出現ABA的情況。（ABA可以查看這篇文章鏈接,關于CAS機制可以看這篇鏈接）

分布式鎖
防重表可以使用分布式鎖代替，比如Redis。訂單發起支付請求，支付系統會去Redis緩存中查詢是否存在該訂單號的Key，如果不存在，則向Redis增加Key為訂單號。查詢訂單支付已經支付，如果沒有則進行支付，支付完成后刪除該訂單號的Key。通過Redis做到了分布式鎖，只有這次訂單訂單支付請求完成，下次請求才能進來。相比去重表，將放并發做到了緩存中，較為高效。思路相同，同一時間只能完成一次支付請求。

總結

以上是生活随笔為你收集整理的幂等性问题和解决方法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。