之前負責的項目報了一個問題,用戶操作回退失效。我們的設計裏,操作回退是回到操作前的狀態。經過查看日誌發現,用戶之前的操作做了兩次,也就是說提交操作的接口被調用了兩次,導致之用戶上一次的狀態和這一次的狀態是一樣的,所以操作回退是沒有問題的,問題出在了操作的接口被調用了兩次。
對於防止重複提交,是放在前端控制的,用戶點擊完按鈕之後,後臺返回成功的結果,按鈕就不可見,實踐證明,客戶端的限制操作不是絕對可靠的。
針對上面的場景,就引入了今天的問題,什麼是接口冪等性?如何保證接口冪等性?
另外:整理了一份Java面試寶典完整版PDF,已成文檔
什麼是接口冪等性?
首先看看冪等性的概念:
冪等性原本是數學上的概念,用在接口上就可以理解爲:同一個接口,多次發出同一個請求,必須保證操作只執行一次。 調用接口發生異常並且重複嘗試時,總是會造成系統所無法承受的損失,所以必須阻止這種現象的發生。
比如下面這些情況,如果沒有實現接口冪等性會有很嚴重的後果: 支付接口,重複支付會導致多次扣錢 ;訂單接口,同一個訂單可能會多次創建。
爲什麼會產生接口冪等性問題?
那麼,什麼情況下,會產生接口冪等性的問題呢?
網絡波動, 可能會引起重複請求
用戶重複操作,用戶在操作時候可能會無意觸發多次下單交易,甚至沒有響應而有意觸發多次交易應用
使用了失效或超時重試機制(Nginx重試、RPC重試或業務層重試等)
頁面重複刷新
使用瀏覽器後退按鈕重複之前的操作,導致重複提交表單
使用瀏覽器歷史記錄重複提交表單
瀏覽器重複的HTTP請求
定時任務重複執行
用戶雙擊提交按鈕
如何保證接口冪等性?
那麼最關鍵的來了,如何保證接口冪等性?
解決辦法分爲兩個方向,一個方向是客戶端防止重複調用,一個是服務端進行校驗。當然,客戶端防止重複提交併不是絕對可靠的,優點是實現起來比較簡單。
- 按鈕只可操作一次
一般是提交後把按鈕置灰或loding狀態,消除用戶因爲重複點擊而產生的重複記錄,比如添加操作,由於點擊兩次而產生兩條記錄
- token機制
功能上允許重複提交,但要保證重複提交不產生副作用,比如點擊n次只產生一條記錄,具體實現就是進入頁面時申請一個token,然後後面所有的請求都帶上這個token,後端根據token來避免重複請求。
- 使用Post/Redirect/Get模式
在提交後執行頁面重定向,這就是所謂的Post-Redirect—Get(PRG)模式,簡單來說就是當用戶提交連表單後,跳轉到一個重定向的信息頁面,這樣就避免用戶按F5刷新導致的重複提交,而且也不會出現瀏覽器表單重複提交的警告,也能消除按瀏覽器前進和後退導致同樣重複提交的問題。
- 在session存放特殊標誌
在服務端,生成一個唯一的標識符,將它存入session,同時前端獲取這個標識符的值將它寫入表單的隱藏中,用於用戶輸入信息後點擊一起提交,在服務器端,獲取表單中隱藏字段的值,與session中的唯一標識符比較,相等說明是首次提交,就處理本次請求,然後將session中的唯一標識符移除,不相等則表示是重複提交,不再做處理。
- 使用唯一索引防止新增髒數據
利用數據庫唯一索引機制,當數據重複時,插入數據庫會拋出異常,保證不會出現髒數據。
- 樂觀鎖
如果更新已有數據,可以進行加鎖更新,也可以設計表結構時使用樂觀鎖,通過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+後綴等)獲取分佈式鎖,其他流程執行時獲取鎖就會失敗,也就是同一時間該流程只能有一個能執行成功,執行完成後,釋放分佈式鎖(分佈式鎖要第三方系統提供)。
- 狀態機冪等
在設計單據相關的業務,或者是任務相關的業務,肯定會涉及到狀態機(狀態變更圖),就是業務單據上面有個狀態,狀態在不同的情況下會發生變更,一般情況下存在有限狀態機,這時候,如果狀態機已經處於下一個狀態,這時候來了一個上一個狀態的變更,理論上是不能夠變更的,這樣的話,保證了有限狀態機的冪等。注意:訂單等單據類業務,存在很長的狀態流轉,一定要深刻理解狀態機,對業務系統設計能力提高有很大幫助 。
- 防重表
以支付爲例: 使用唯一主鍵去做防重表的唯一索引,比如使用訂單號作爲防重表的唯一索引,每一次請求都根據訂單號向防重表中插入一條數據,插入成功說明可以處理後面的業務,當處理完業務邏輯之後刪除防重表中的訂單號數據,後續如果有重複請求,則會因爲防重表唯一索引原因導致插入失敗,直接返回操作失敗,直到第一次請求返回結果,可以看出防重表作用就是加鎖的功能。 注: 最好結合狀態機冪等先判斷一下
- 緩衝隊列
將請求都快速地接收下來後放入緩衝隊列中,後續使用異步任務處理隊列中的數據,過濾掉重複的請求,該解決方案優點是同步處理改成異步處理、高吞吐量,缺點則是不能及時地返回請求結果,需要後續輪詢得處理結果。
- 全局唯一號
比如通過source來源 + 唯一序列號傳入給後端,後端來判斷請求是否重複,在併發時只能處理一個請求,其他相同併發請求要麼返回請求重複,要麼等待 前面請求執行完成後再執行。
作者:三分惡
原文鏈接:https://www.cnblogs.com/three-fighter/p/14054749.html