在實際的開發項目中,一個對外暴露的接口往往會面臨很多次請求。這就需要考慮到一個冪等性問題。
冪等性
冪等性的概念是：任意多次執行所產生的影響均與一次執行的影響相同，即無論你請求了多少次，對數據庫的影響都只能有一次，不能重複處理。
所以，按照上面的理解，每次執行的結果都會發生變化，就是非冪等的。如下面三條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做到了分佈式鎖，只有這次訂單訂單支付請求完成，下次請求才能進來。相比去重表，將放併發做到了緩存中，較爲高效。思路相同，同一時間只能完成一次支付請求。
