介面冪等
- 什么是介面冪等？
- 為什么介面需要冪等性設計
- 前端重復提交表單
- 黑客惡意攻擊
- 介面超時重復提交
- 訊息重復消費
- 哪些介面需要冪等？
- 如何實作冪等
- 前端攔截
- 資料庫唯一索引實作
- 資料庫樂觀鎖實作
- 資料庫悲觀鎖實作
- JVM鎖實作
- 分布式鎖實作
- Token實作
- 總結
介面冪等-冪等性-介面的冪等性-分布式冪等性-如何保證冪等-冪等性實作方案-去重表-下單冪等-支付冪等-扣還庫存冪等
什么是介面冪等？
在計算機中編程中，一個冪等操作的特點是其任意多次執行所產生的影響均與第一次執行的影響相同，
介面的冪等性實際上就是介面可重復呼叫，在呼叫方多次呼叫的情況下，介面最終得到的結果是一致的，有些介面可以天然的實作冪等性，比如查詢介面，對于查詢來說，你查詢一次和兩次，對于系統來說，沒有任何影響，查出的結果也是一樣，
為什么介面需要冪等性設計
該問題等同于 為什么會重復呼叫？
前端重復提交表單
在填寫一些表格時候，用戶填寫完成提交，很多時候會因網路波動沒有及時對用戶做出提交成功回應，致使用戶認為沒有成功提交，然后一直點提交按鈕，這時就會發生重復提交表單請求，
黑客惡意攻擊
例如在實作用戶投票這種功能時，如果黑客針對一個用戶進行重復提交投票，這樣會導致介面接收到用戶重復提交的投票資訊，這樣會使投票結果與事實嚴重不符，
介面超時重復提交
大部分RPC框架[比如Dubbo]，為了防止網路波動超時等造成的請求失敗，都會添加重試機制，導致一個請求提交多次，
訊息重復消費
當使用 MQ 訊息中間件時候，如果Consumer消費超時或者producer發送了訊息但由于網路原因未收到ACK導致訊息重發，都會導致重復消費，
哪些介面需要冪等？
冪等性的實作與判斷需要消耗一定的資源，因此不應該給每個介面都增加冪等性判斷，要根據實際的業務情況和操作型別來進行區分，例如，我們在進行查詢操作和洗掉操作時就無須進行冪等性判斷，查詢操作查一次和查多次的結果都是一致的，因此我們無須進行冪等性判斷，洗掉操作也是一樣，洗掉一次和洗掉多次都是把相關的資料進行洗掉（這里的洗掉指的是條件洗掉而不是洗掉所有資料），因此也無須進行冪等性判斷，
所以到底哪些介面需要冪等？關于這個問題需要從具體業務出發，但是也有規律可循如下表：
| 介面型別 | 是否冪等 | 描述 |
|---|---|---|
| GET | √ | Get方法用于獲取資源，其一般不會也不應當對系統資源進行改變，所以是冪等的， |
| POST | × | Post方法一般用于創建新的資源，其每次執行都會新增資料，所以不是冪等的， |
| PUT | - | Put方法一般用于修改資源，該操作則分情況來判斷是不是滿足冪等，更新操作中直接根據某個值進行更新，也能保持冪等，不過執行索加操作的更新是非冪等， |
| DELETE | - | Delete方法一般用于洗掉資源，該操作則分情況來判斷是不是滿足冪等，當根據唯一值進行洗掉時，洗掉同一個資料多次執行效果一樣，不過需要注意，帶查詢條件的洗掉則就不一定滿足冪等了，例如在根據條件洗掉一批資料后，這時候新增加了一條資料也滿只條件，然后又執行了—次洗掉，那么將會導致新增加的這條滿足條件資料也被洗掉， |
如何實作冪等
前端攔截
前端攔截是指通過 Web 站點的頁面進行請求攔截，比如在用戶點擊完“提交”按鈕后，我們可以把按鈕設定為不可用或者隱藏狀態，避免用戶重復點擊，
該方法可以解決用戶誤操作提交兩次表單所產生的重復提交問題，但前端攔截有一個致命的問題，如果是懂行的程式員或者黑客可以直接繞過頁面的 JS 執行，直接模擬請求后端的介面，這樣的話，我們前端的這些攔截就不能生效了，因此除了前端攔截一部分正常的誤操作之外，后端的驗證必不可少，
資料庫唯一索引實作
資料庫唯一索引實作方案一般只能適用于執行插入操作的程序，
具體流程步驟：
- 建立一張去重表，其中某個欄位需要建立唯一索引
- 客戶端去請求服務端，服務端會將這次請求的一些資訊插入這張去重表中
- 因為表中某個欄位帶有唯一索引，如果插入成功，證明表中沒有這次請求的資訊，則執行后續的業務邏輯
- 如果插入失敗，則代表已經執行過當前請求，直接回傳
資料庫樂觀鎖實作
資料庫樂觀鎖方案一般只能適用于執行更新操作的程序，我們可以提前在對應的資料表中多添加一個欄位，充當當前資料的版本標識，
這樣每次對該資料庫該表的這條資料執行更新時，都會將該版本標識作為一個條件，值為上次待更新資料中的版本標識的值，
具體流程步驟：
- 客戶端帶著version欄位請求服務端
- 服務端執行update的時候需要給version+1，并且需要加version的更新條件如下SQL
update t set stock = stock - 1 , version = version + 1 where id = #{id} and version = #{version}
資料庫悲觀鎖實作
具體流程步驟：
- 客戶端通過業務id，訪問服務端
- 先查資料庫是否存在該業務id，查庫的時候需要加X鎖
- 如果存在則說明是重復請求，不存在則進行業務邏輯處理
JVM鎖實作
JVM 鎖實作是指通過 JVM 提供的內置鎖如 Lock 或者是 synchronized 來實作冪等性，使用 JVM 鎖來實作冪等性的一般流程為：首先通過 Lock 對代碼段進行加鎖操作，然后再判斷此訂單是否已經被處理過，如果未處理則開啟事務執行訂單處理，處理完成之后提交事務并釋放鎖，執行流程如下圖所示：
JVM 鎖存在的最大問題在于，它只能應用于單機環境，因為 Lock 本身為單機鎖，所以它就不適應于分布式多機環境，
分布式鎖實作
分布式鎖實作解決JVM鎖實作單機鎖局限問題，
具體流程步驟：
- 客戶端先請求服務端，會拿到一個能代表這次請求業務的唯一欄位
- 將該欄位以 SETNX 的方式存入 redis 中，并根據業務設定相應的超時時間
- 如果設定成功，證明這是第一次請求，則執行后續的業務邏輯
- 如果設定失敗，則代表已經執行過當前請求，直接回傳
Token實作
具體流程步驟：
- 客戶端會先發送一個請求去獲取 token，服務端會生成一個全域唯一的 ID 作為 token 保存在 redis 中，同時把這個 ID 回傳給客戶端
- 客戶端第二次呼叫業務請求的時候必須攜帶這個 token
- 服務端會校驗這個 token，如果校驗成功，則執行業務，并洗掉 redis 中的 token
- 如果校驗失敗，說明 redis 中已經沒有對應的 token，則表示重復操作，直接回傳指定的結果給客戶端
注意：
對 redis 中是否存在 token 以及洗掉的代碼邏輯建議用 Lua 腳本實作，保證原子性
全域唯一 ID 可以用百度的 uid-generator、美團的 Leaf 去生成
總結
冪等性不但可以保證程式正常執行，還可以杜絕一些垃圾資料以及無效請求對系統資源的消耗，推薦使用分布式鎖來實作，這樣的解決方案更加通用，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/273332.html
標籤：其他