故事

又是一個(gè)風(fēng)和日麗美好的一天，小貓戴著耳機(jī)，安逸地聽著音樂，擼著代碼，這種沒有會(huì)議的日子真的是巴適得板。

不料禍從天降，組長火急火燎地跑過來找到了小貓。“快排查一下，目前有A公司用戶反饋積分被多扣了”。

小貓回憶了一下“不對(duì)啊，這接口我也沒動(dòng)過啊，前幾天對(duì)外平臺(tái)的老六直接找我要個(gè)支付接口，我就給他了的，以前的代碼，我都沒有動(dòng)過的......”。

于是小貓一邊疑惑一邊翻看著以前的代碼，越看臉色越差......

小貓做的是一個(gè)標(biāo)準(zhǔn)的積分兌換商城，以前和客戶合作的時(shí)候，客戶直接用的是小貓單位自己定制的h5頁面。這次合作了一家公司有點(diǎn)特殊，由于公司想要定制化自己個(gè)性化的H5，加上本身A公司自己有開發(fā)能力，所以經(jīng)過討論就以接口的方式直接將相關(guān)接口給出去，A客戶H5開發(fā)完成之后自己來對(duì)接。

慢慢地，原因也水落石出，之前好好的業(yè)務(wù)一直沒有問題是因?yàn)樯坛堑谋旧鞨5頁面做了防重復(fù)提交，由于量小，并且一般對(duì)接方式用的都是純H5，所以都沒有什么問題，然后這次是直接將接口給出去了，完了接口居然沒有加冪等......

小貓?zhí)蓸專瑪?shù)據(jù)訂正當(dāng)然是少不了了，事故報(bào)告當(dāng)然也少不了了。

正所謂前人挖坑，后人遭殃，前人鍋后人背。

聊聊冪等

1.接口冪等梗概

這個(gè)案例其實(shí)就是一個(gè)典型的接口冪等案例。那么老貓就和大家從以下幾個(gè)方面好好剖析一下接口冪等吧。

2.什么是接口冪等

比較專業(yè)的術(shù)語：其任意多次執(zhí)行所產(chǎn)生的影響均與第一次執(zhí)行的影響相同。大白話：多次調(diào)用的情況下，接口最終得到的結(jié)果是一致的。

3.那么為什么需要冪等呢？

• 用戶進(jìn)行提交動(dòng)作的時(shí)候，由于網(wǎng)絡(luò)波動(dòng)等原因?qū)е潞蠖送巾憫?yīng)不及時(shí)，這樣用戶就會(huì)一直點(diǎn)點(diǎn)點(diǎn)，這樣機(jī)會(huì)發(fā)生重復(fù)提交的情況。
• 分布式系統(tǒng)之間調(diào)用的情況下，例如RPC調(diào)用，為了防止網(wǎng)絡(luò)波動(dòng)超時(shí)等造成的請(qǐng)求失敗，都會(huì)添加重試機(jī)制，導(dǎo)致一個(gè)請(qǐng)求提交多次。
• 分布式系統(tǒng)經(jīng)常會(huì)用到消息中間件，當(dāng)由于網(wǎng)絡(luò)原因，mq沒有收到ack的情況下，就會(huì)導(dǎo)致消息的重復(fù)投遞，從而就會(huì)導(dǎo)致重復(fù)提交行為。

還有就是惡意攻擊了，有些業(yè)務(wù)接口做的比較粗糙，黑客找到漏洞之后會(huì)發(fā)起重復(fù)提交，這樣就會(huì)導(dǎo)致業(yè)務(wù)出現(xiàn)問題。打個(gè)比方，老貓?jiān)?jīng)干過，鄰居小孩報(bào)名了一個(gè)畫畫比賽，估計(jì)是機(jī)構(gòu)培訓(xùn)發(fā)起的，功能做的也差，需要靠投票贏得某些禮品，然后老貓抓到接口信息之后就模擬投票進(jìn)行重復(fù)刷了投票。

4.那么哪些接口需要做冪等呢？

首先我們說是不是所有的接口都需要冪等？是不是加了冪等就好呢？顯然不是。因?yàn)榻涌趦绲鹊膶?shí)現(xiàn)某種意義上是要消耗系統(tǒng)性能的，我們沒有必要針對(duì)所有業(yè)務(wù)接口都加上冪等。

這個(gè)其實(shí)并不能做一個(gè)完全的定義說哪個(gè)就不用冪等，因?yàn)楹芏鄷r(shí)候其實(shí)還是得結(jié)合業(yè)務(wù)邏輯一起看。但是其中也是有規(guī)律可循的。

既然我們說冪等就是多次調(diào)用，接口最終得到結(jié)果一致，那么很顯然，查詢接口肯定是不要加冪等的，另外一些簡單刪除數(shù)據(jù)的接口，無論是邏輯刪除還是物理刪除，看場(chǎng)景的情況下其實(shí)也不用加冪等。

但是大部分涉及到多表更新行為的接口，咱們最好還是得加上冪等。

接口冪等實(shí)戰(zhàn)方案

1.前端防抖處理

前端防抖主要可以有兩種方案，一種是技術(shù)層面的，一種是產(chǎn)品層面的：

• 技術(shù)層面：例如提交控制在100ms內(nèi)，同一個(gè)用戶最多只能做一次訂單提交的操作。
• 產(chǎn)品層面：當(dāng)然用戶點(diǎn)擊提交之后，按鈕直接置灰。

2.基于數(shù)據(jù)庫唯一索引

利用數(shù)據(jù)庫唯一索引。我們具體來看一下流程，咱們就用小貓遇到的例子。如下：

過程描述：

• 建立一張去重表，其中某個(gè)字段需要建立唯一索引，例如小貓這個(gè)場(chǎng)景中，咱們就可以將訂單提交流水單號(hào)作為唯一索引存儲(chǔ)到我們的數(shù)據(jù)庫中，就模型上而言，可以將其定義為支付請(qǐng)求流水表。
• 客戶端攜帶相關(guān)流水信息到后端，如果發(fā)現(xiàn)編號(hào)重復(fù)，那么此時(shí)就會(huì)插入失敗，報(bào)主鍵沖突的錯(cuò)誤，此時(shí)我們針對(duì)該錯(cuò)誤做一下業(yè)務(wù)報(bào)錯(cuò)的二次封裝給到客戶另一個(gè)友好的提示即可。

3.數(shù)據(jù)庫樂觀鎖實(shí)現(xiàn)

什么是樂觀鎖，它假設(shè)多用戶并發(fā)的事務(wù)在處理時(shí)不會(huì)彼此互相影響，各事務(wù)能夠在不產(chǎn)生鎖的情況下處理各自影響的那部分?jǐn)?shù)據(jù)。說得直白一點(diǎn)樂觀鎖就是一個(gè)馬大哈。總是假設(shè)最好的情況，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改，所以不會(huì)上鎖，只在更新的時(shí)候會(huì)判斷一下在此期間別人有沒有去更新這個(gè)數(shù)據(jù)。

例如提交訂單的進(jìn)行支付扣款的時(shí)候，本來可能更新賬戶金額扣款的動(dòng)作是這樣的：

update Account set balance = balance-#{payAmount} where accountCode = #{accountCode}

加上版本號(hào)之后，咱們的代碼就是這樣的：

update Account set balance = balance-#{payAmount},version=version +1 where accountCode = #{accountCode} and version = #{currVersion}

這種情況下其實(shí)就要求客戶端每次在請(qǐng)求支付下單的時(shí)候都需要上層客戶端指定好當(dāng)前的版本信息。不過這種冪等的處理方式，老貓用的比較少。

4.數(shù)據(jù)庫悲觀鎖實(shí)現(xiàn)

悲觀鎖的話具有強(qiáng)烈的獨(dú)占和排他特性。大白話誰都不信的主。所以我們就用select ... for update這樣的語法進(jìn)行行鎖，當(dāng)然老貓覺得單純的select ... for update只能解決同一時(shí)刻大并發(fā)的冪等，所以要保證單號(hào)重試這樣非并發(fā)的冪等請(qǐng)求還是得去校驗(yàn)當(dāng)前數(shù)據(jù)的狀態(tài)才行。就拿當(dāng)前的小貓遇到的場(chǎng)景來說，流程如下：

悲觀鎖

begin;  # 1.開始事務(wù)
select * from order where order_code='666' for update # 查詢訂單，判斷狀態(tài),鎖住這條記錄
if（status !=處理中）{
   //非處理中狀態(tài)，直接返回；
   return ;
}
## 處理業(yè)務(wù)邏輯
update order set status='完成' where order_code='666' # 更新完成
update stock set num = num - 1 where spu='xxx' # 庫存更新
commit; # 5.提交事務(wù)

這里老貓一再想要強(qiáng)調(diào)的是在校驗(yàn)的時(shí)候還是得帶上本身的業(yè)務(wù)狀態(tài)去做校驗(yàn)，select ... for update并非萬能冪等。

5.后端生成token

這個(gè)方案的本質(zhì)其實(shí)是引入了令牌桶的機(jī)制，當(dāng)提交訂單的時(shí)候，前端優(yōu)先會(huì)調(diào)用后端接口獲取一個(gè)token，token是由后端發(fā)放的。當(dāng)然token的生成方式有很多種，例如定時(shí)刷新令牌桶，或者定時(shí)生成令牌并放到令牌池中，當(dāng)然目的只有一個(gè)就是保住token的唯一性即可。

生成token之后將token放到redis中，當(dāng)然需要給token設(shè)置一個(gè)失效時(shí)間，超時(shí)的token也會(huì)被刪除。

當(dāng)后端接收到訂單提交的請(qǐng)求的時(shí)候，會(huì)先判斷token在緩存中是否存在，第一次請(qǐng)求的時(shí)候，token一定存在，也會(huì)正常返回結(jié)果，但是第二次攜帶同一個(gè)token的時(shí)候被拒絕了。

流程如下：

token機(jī)制

有個(gè)注意點(diǎn)大家可以思考一下：如果用戶用程序惡意刷單，同一個(gè)token發(fā)起了多次請(qǐng)求怎么辦？想要實(shí)現(xiàn)這個(gè)功能，就需要借助分布式鎖以及Lua腳本了，分布式鎖可以保證同一個(gè)token不能有多個(gè)請(qǐng)求同時(shí)過來訪問，lua腳本保證從redis中獲取令牌->比對(duì)令牌->生成單號(hào)->刪除令牌這一系列行為的原子性。

6.分布式鎖+狀態(tài)機(jī)（訂單狀態(tài)）

現(xiàn)在很多的業(yè)務(wù)服務(wù)都是分布式系統(tǒng)，所以就拿分布式鎖來說，關(guān)于分布式鎖，老貓?jiān)诖瞬蛔鲑樖觯袄县垖戇^redis的分布式鎖和實(shí)現(xiàn)，還有zk鎖和實(shí)現(xiàn)，具體可見鏈接：

• 鎖的演化
• 手撕redis分布式鎖
• 手?jǐn)]ZK鎖

當(dāng)然和上述的數(shù)據(jù)庫悲觀鎖類似，咱們的分布式鎖也只能保證同一個(gè)訂單在同一時(shí)間的處理。其次也是要去校訂單的狀態(tài)，防止其重復(fù)支付的，也就是說，只要支付的訂單進(jìn)入后端，都要將原先的訂單修改為支付中，防止后續(xù)支付中斷之后的重復(fù)支付。

在上述小貓的流程中還沒有涉及到現(xiàn)金補(bǔ)充，如果涉及到現(xiàn)金補(bǔ)充的話，例如對(duì)接了微信或者支付寶的情況，還需要根據(jù)最終的支付回調(diào)結(jié)果來最終將訂單狀態(tài)進(jìn)行流轉(zhuǎn)成支付完成或者是支付失敗。

總結(jié)

在我們?nèi)粘５拈_發(fā)中，一些重要的接口還是需要大家謹(jǐn)慎對(duì)待，即使是前任開發(fā)留下的接口，沒有任何改動(dòng)，當(dāng)有人咨詢的時(shí)候，其實(shí)就要好好去了解一下里面的實(shí)現(xiàn)，看看方案有沒有問題，看看技術(shù)實(shí)現(xiàn)有沒有問題，這應(yīng)該也是每一個(gè)程序員的基本素養(yǎng)。

另外的，在一些重要的接口上，尤其是資金相關(guān)的接口上，冪等真的是相當(dāng)?shù)闹匾Ｐ』锇閭儯銈冇X得呢？