之前負(fù)責(zé)的項(xiàng)目報(bào)了一個(gè)問題，用戶操作回退失效。我們的設(shè)計(jì)里，操作回退是回到操作前的狀態(tài)。經(jīng)過查看日志發(fā)現(xiàn)，用戶之前的操作做了兩次，也就是說提交操作的接口被調(diào)用了兩次，導(dǎo)致之用戶上一次的狀態(tài)和這一次的狀態(tài)是一樣的，所以操作回退是沒有問題的，問題出在了操作的接口被調(diào)用了兩次。

對(duì)于防止重復(fù)提交，是放在前端控制的，用戶點(diǎn)擊完按鈕之后，后臺(tái)返回成功的結(jié)果，按鈕就不可見，實(shí)踐證明，客戶端的限制操作不是絕對(duì)可靠的。

針對(duì)上面的場(chǎng)景，就引入了今天的問題，什么是接口冪等性?如何保證接口冪等性?

什么是接口冪等性?

首先看看冪等性的概念：

• 冪等性原本是數(shù)學(xué)上的概念，用在接口上就可以理解為：同一個(gè)接口，多次發(fā)出同一個(gè)請(qǐng)求，必須保證操作只執(zhí)行一次。 調(diào)用接口發(fā)生異常并且重復(fù)嘗試時(shí)，總是會(huì)造成系統(tǒng)所無法承受的損失，所以必須阻止這種現(xiàn)象的發(fā)生。

比如下面這些情況，如果沒有實(shí)現(xiàn)接口冪等性會(huì)有很嚴(yán)重的后果： 支付接口，重復(fù)支付會(huì)導(dǎo)致多次扣錢 ;訂單接口，同一個(gè)訂單可能會(huì)多次創(chuàng)建。

為什么會(huì)產(chǎn)生接口冪等性問題?

那么，什么情況下，會(huì)產(chǎn)生接口冪等性的問題呢?

• 網(wǎng)絡(luò)波動(dòng), 可能會(huì)引起重復(fù)請(qǐng)求
• 用戶重復(fù)操作,用戶在操作時(shí)候可能會(huì)無意觸發(fā)多次下單交易,甚至沒有響應(yīng)而有意觸發(fā)多次交易應(yīng)用
• 使用了失效或超時(shí)重試機(jī)制(Nginx重試、RPC重試或業(yè)務(wù)層重試等)
• 頁(yè)面重復(fù)刷新
• 使用瀏覽器后退按鈕重復(fù)之前的操作,導(dǎo)致重復(fù)提交表單
• 使用瀏覽器歷史記錄重復(fù)提交表單
• 瀏覽器重復(fù)的HTTP請(qǐng)求
• 定時(shí)任務(wù)重復(fù)執(zhí)行
• 用戶雙擊提交按鈕

如何保證接口冪等性?

那么最關(guān)鍵的來了，如何保證接口冪等性?

解決辦法分為兩個(gè)方向，一個(gè)方向是客戶端防止重復(fù)調(diào)用，一個(gè)是服務(wù)端進(jìn)行校驗(yàn)。當(dāng)然，客戶端防止重復(fù)提交并不是絕對(duì)可靠的，優(yōu)點(diǎn)是實(shí)現(xiàn)起來比較簡(jiǎn)單。

按鈕只可操作一次

一般是提交后把按鈕置灰或loding狀態(tài),消除用戶因?yàn)橹貜?fù)點(diǎn)擊而產(chǎn)生的重復(fù)記錄,比如添加操作,由于點(diǎn)擊兩次而產(chǎn)生兩條記錄

token機(jī)制

功能上允許重復(fù)提交,但要保證重復(fù)提交不產(chǎn)生副作用,比如點(diǎn)擊n次只產(chǎn)生一條記錄,具體實(shí)現(xiàn)就是進(jìn)入頁(yè)面時(shí)申請(qǐng)一個(gè)token,然后后面所有的請(qǐng)求都帶上這個(gè)token,后端根據(jù)token來避免重復(fù)請(qǐng)求。

使用Post/Redirect/Get模式

在提交后執(zhí)行頁(yè)面重定向,這就是所謂的Post-Redirect—Get(PRG)模式,簡(jiǎn)單來說就是當(dāng)用戶提交連表單后,跳轉(zhuǎn)到一個(gè)重定向的信息頁(yè)面,這樣就避免用戶按F5刷新導(dǎo)致的重復(fù)提交,而且也不會(huì)出現(xiàn)瀏覽器表單重復(fù)提交的警告,也能消除按瀏覽器前進(jìn)和后退導(dǎo)致同樣重復(fù)提交的問題。

在session存放特殊標(biāo)志

在服務(wù)端,生成一個(gè)唯一的標(biāo)識(shí)符,將它存入session,同時(shí)前端獲取這個(gè)標(biāo)識(shí)符的值將它寫入表單的隱藏中,用于用戶輸入信息后點(diǎn)擊一起提交,在服務(wù)器端,獲取表單中隱藏字段的值,與session中的唯一標(biāo)識(shí)符比較,相等說明是首次提交,就處理本次請(qǐng)求,然后將session中的唯一標(biāo)識(shí)符移除,不相等則表示是重復(fù)提交,不再做處理。

使用唯一索引防止新增臟數(shù)據(jù)

利用數(shù)據(jù)庫(kù)唯一索引機(jī)制,當(dāng)數(shù)據(jù)重復(fù)時(shí),插入數(shù)據(jù)庫(kù)會(huì)拋出異常,保證不會(huì)出現(xiàn)臟數(shù)據(jù)。

樂觀鎖

如果更新已有數(shù)據(jù),可以進(jìn)行加鎖更新,也可以設(shè)計(jì)表結(jié)構(gòu)時(shí)使用樂觀鎖,通過version來做樂觀鎖,這樣既能保證執(zhí)行效率,又能保證冪等, 樂觀鎖的version版本在更新業(yè)務(wù)數(shù)據(jù)要自增

update table set version = version + 1 where id = #{id} and version = #{version}

示例: 當(dāng)有重復(fù)請(qǐng)求的時(shí)候,第一個(gè)請(qǐng)求會(huì)獲取當(dāng)前商品的version版本號(hào),得到的version為1,緊接著由于第一個(gè)請(qǐng)求還沒更新商品的version,第二個(gè)請(qǐng)求獲取的version依然也是1, 這時(shí)候第一個(gè)請(qǐng)求操作更新的時(shí)候帶上version并作為條件并且自增更新,這時(shí)候商品的version就會(huì)變成2,當(dāng)?shù)诙€(gè)請(qǐng)求去操作更新的時(shí)候明顯version不一致導(dǎo)致更新失敗。

select + insert or update or delete

該方案就是操作之前先查詢一下,符合要求再插入,該方案在沒有并發(fā)的系統(tǒng)中可以解決冪等問題，在單JVM有并發(fā)的時(shí)候可以用JVM加鎖來保證冪等性,在分布式環(huán)境它是無法保證冪等性,可以使用分布式來保證。

分布式鎖

如果是分布是系統(tǒng)，構(gòu)建全局唯一索引比較困難，例如唯一性的字段沒法確定，這時(shí)候可以引入分布式鎖，通過第三方的系統(tǒng)(redis或zookeeper)，在業(yè)務(wù)系統(tǒng)插入數(shù)據(jù)或者更新數(shù)據(jù)，獲取分布式鎖，然后做操作，之后釋放鎖，這樣其實(shí)是把多線程并發(fā)的鎖的思路，引入多多個(gè)系統(tǒng)，也就是分布式系統(tǒng)中得解決思路。要點(diǎn)：某個(gè)長(zhǎng)流程處理過程要求不能并發(fā)執(zhí)行，可以在流程執(zhí)行之前根據(jù)某個(gè)標(biāo)志(用戶ID+后綴等)獲取分布式鎖，其他流程執(zhí)行時(shí)獲取鎖就會(huì)失敗，也就是同一時(shí)間該流程只能有一個(gè)能執(zhí)行成功，執(zhí)行完成后，釋放分布式鎖(分布式鎖要第三方系統(tǒng)提供)。

狀態(tài)機(jī)冪等

在設(shè)計(jì)單據(jù)相關(guān)的業(yè)務(wù)，或者是任務(wù)相關(guān)的業(yè)務(wù)，肯定會(huì)涉及到狀態(tài)機(jī)(狀態(tài)變更圖)，就是業(yè)務(wù)單據(jù)上面有個(gè)狀態(tài)，狀態(tài)在不同的情況下會(huì)發(fā)生變更，一般情況下存在有限狀態(tài)機(jī)，這時(shí)候，如果狀態(tài)機(jī)已經(jīng)處于下一個(gè)狀態(tài)，這時(shí)候來了一個(gè)上一個(gè)狀態(tài)的變更，理論上是不能夠變更的，這樣的話，保證了有限狀態(tài)機(jī)的冪等。注意：訂單等單據(jù)類業(yè)務(wù)，存在很長(zhǎng)的狀態(tài)流轉(zhuǎn)，一定要深刻理解狀態(tài)機(jī)，對(duì)業(yè)務(wù)系統(tǒng)設(shè)計(jì)能力提高有很大幫助 。

防重表

以支付為例: 使用唯一主鍵去做防重表的唯一索引,比如使用訂單號(hào)作為防重表的唯一索引,每一次請(qǐng)求都根據(jù)訂單號(hào)向防重表中插入一條數(shù)據(jù),插入成功說明可以處理后面的業(yè)務(wù),當(dāng)處理完業(yè)務(wù)邏輯之后刪除防重表中的訂單號(hào)數(shù)據(jù),后續(xù)如果有重復(fù)請(qǐng)求,則會(huì)因?yàn)榉乐乇砦ㄒ凰饕驅(qū)е虏迦胧?直接返回操作失敗,直到第一次請(qǐng)求返回結(jié)果,可以看出防重表作用就是加鎖的功能。

注: 最好結(jié)合狀態(tài)機(jī)冪等先判斷一下

緩沖隊(duì)列

將請(qǐng)求都快速地接收下來后放入緩沖隊(duì)列中,后續(xù)使用異步任務(wù)處理隊(duì)列中的數(shù)據(jù),過濾掉重復(fù)的請(qǐng)求,該解決方案優(yōu)點(diǎn)是同步處理改成異步處理、高吞吐量,缺點(diǎn)則是不能及時(shí)地返回請(qǐng)求結(jié)果,需要后續(xù)輪詢得處理結(jié)果。

全局唯一號(hào)

比如通過source來源 + 唯一序列號(hào)傳入給后端，后端來判斷請(qǐng)求是否重復(fù),在并發(fā)時(shí)只能處理一個(gè)請(qǐng)求,其他相同并發(fā)請(qǐng)求要么返回請(qǐng)求重復(fù),要么等待 前面請(qǐng)求執(zhí)行完成后再執(zhí)行。