本文已經收錄到Github倉庫，該倉庫包含電腦基礎、Java基礎、多線程、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分散式、微服務、設計模式、架構、校招社招分享等核心知識點，歡迎star~ Github地址 大家好，我是大彬~ 今天來聊聊接 ...
本文已經收錄到Github倉庫，該倉庫包含電腦基礎、Java基礎、多線程、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分散式、微服務、設計模式、架構、校招社招分享等核心知識點，歡迎star~
大家好，我是大彬~
今天來聊聊介面冪等性。
什麼是介面冪等性？如何保證介面冪等性？
什麼是介面冪等性？
首先看看冪等性的概念：
冪等性原本是數學上的概念，用在介面上就可以理解為：同一個介面，多次發出同一個請求，必須保證操作只執行一次。調用介面發生異常並且重覆嘗試時，總是會造成系統所無法承受的損失，所以必須阻止這種現象的發生。
比如下麵這些情況，如果沒有實現介面冪等性會有很嚴重的後果：支付介面，重覆支付會導致多次扣錢 ；訂單介面，同一個訂單可能會多次創建。
為什麼會產生介面冪等性問題？
那麼，什麼情況下，會產生介面冪等性的問題呢？
- 網路波動, 可能會引起重覆請求
- 用戶重覆操作,用戶在操作時候可能會無意觸發多次下單交易,甚至沒有響應而有意觸發多次交易應用
- 使用了失效或超時重試機制(Nginx重試、RPC重試或業務層重試等)
- 頁面重覆刷新
- 使用瀏覽器後退按鈕重覆之前的操作,導致重覆提交表單
- 使用瀏覽器歷史記錄重覆提交表單
- 瀏覽器重覆的HTTP請求
- 定時任務重覆執行
- 用戶雙擊提交按鈕
如何保證介面冪等性？
那麼最關鍵的來了，如何保證介面冪等性？
解決辦法分為兩個方向，一個方向是客戶端防止重覆調用，一個是服務端進行校驗。當然，客戶端防止重覆提交並不是絕對可靠的，優點是實現起來比較簡單。
按鈕只可操作一次
一般是提交後把按鈕置灰或loding狀態,消除用戶因為重覆點擊而產生的重覆記錄,比如添加操作,由於點擊兩次而產生兩條記錄。
token機制
功能上允許重覆提交,但要保證重覆提交不產生副作用,比如點擊n次只產生一條記錄,具體實現就是進入頁面時申請一個token,然後後面所有的請求都帶上這個token,後端根據token來避免重覆請求。
使用唯一索引防止新增臟數據
利用資料庫唯一索引機制,當數據重覆時,插入資料庫會拋出異常,保證不會出現臟數據。
樂觀鎖
如果更新已有數據,可以進行加鎖更新,也可以設計表結構時使用樂觀鎖,通過version來做樂觀鎖,這樣既能保證執行效率,又能保證冪等, 樂觀鎖的version版本在更新業務數據要自增。
update table set version = version + 1 where id = #{id} and version = #{version}
示例: 當有重覆請求的時候,第一個請求會獲取當前商品的version版本號,得到的version為1,緊接著由於第一個請求還沒更新商品的version,第二個請求獲取的version依然也是1, 這時候第一個請求操作更新的時候帶上version並作為條件並且自增更新,這時候商品的version就會變成2,當第二個請求去操作更新的時候明顯version不一致導致更新失敗。
select + insert or update or delete
該方案就是操作之前先查詢一下,符合要求再插入,該方案在沒有併發的系統中可以解決冪等問題，在單JVM有併發的時候可以用JVM加鎖來保證冪等性,在分散式環境它是無法保證冪等性,可以使用分散式來保證。
分散式鎖
如果是分散式系統，構建全局唯一索引比較困難，例如唯一性的欄位沒法確定，這時候可以引入分散式鎖，通過第三方的系統(redis或zookeeper)，在業務系統插入數據或者更新數據，獲取分散式鎖，然後做操作，之後釋放鎖。要點：某個長流程處理過程要求不能併發執行，可以在流程執行之前根據某個標誌(用戶ID+尾碼等)獲取分散式鎖，其他流程執行時獲取鎖就會失敗，也就是同一時間該流程只能有一個能執行成功，執行完成後，釋放分散式鎖(分散式鎖要第三方系統提供)。
狀態機冪等
在設計單據相關的業務，或者是任務相關的業務，肯定會涉及到狀態機(狀態變更圖)，就是業務單據上面有個狀態，狀態在不同的情況下會發生變更，一般情況下存在有限狀態機，這時候，如果狀態機已經處於下一個狀態，這時候來了一個上一個狀態的變更，理論上是不能夠變更的，這樣的話，保證了有限狀態機的冪等。註意：訂單等單據類業務，存在很長的狀態流轉，一定要深刻理解狀態機，對業務系統設計能力提高有很大幫助 。
防重表
以支付為例: 使用唯一主鍵去做防重表的唯一索引,比如使用訂單號作為防重表的唯一索引,每一次請求都根據訂單號向防重表中插入一條數據,插入成功說明可以處理後面的業務,當處理完業務邏輯之後刪除防重表中的訂單號數據,後續如果有重覆請求,則會因為防重表唯一索引原因導致插入失敗,直接返回操作失敗,直到第一次請求返回結果,可以看出防重表作用就是加鎖的功能。
註: 最好結合狀態機冪等先判斷一下
緩衝隊列
將請求都快速地接收下來後放入緩衝隊列中,後續使用非同步任務處理隊列中的數據,過濾掉重覆的請求,該解決方案優點是同步處理改成非同步處理、高吞吐量,缺點則是不能及時地返回請求結果,需要後續輪詢得處理結果。
最後給大家分享一個Github倉庫，上面有大彬整理的300多本經典的電腦書籍PDF，包括C語言、C++、Java、Python、前端、資料庫、操作系統、電腦網路、數據結構和演算法、機器學習、編程人生等，可以star一下，下次找書直接在上面搜索，倉庫持續更新中~
