故事

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

不料禍從天降，組長火急火燎地跑過來找到了小貓?！翱炫挪橐幌?，目前有A公司用戶反饋積分被多扣了”。

小貓回憶了一下“不對啊，這接口我也沒動過啊，前幾天對外平臺的老六直接找我要個支付接口，我就給他了的，以前的代碼，我都沒有動過的......”。

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

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

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

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

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

聊聊冪等

1.接口冪等梗概

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

2.什么是接口冪等

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

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

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

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

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

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

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

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

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

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

1.前端防抖處理

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

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

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

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

過程描述：

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

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

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

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

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

加上版本號之后，咱們的代碼就是這樣的：

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

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

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

悲觀鎖的話具有強(qiáng)烈的獨(dú)占和排他特性。大白話誰都不信的主。所以我們就用select ... for update這樣的語法進(jìn)行行鎖，當(dāng)然老貓覺得單純的select ... for update只能解決同一時刻大并發(fā)的冪等，所以要保證單號重試這樣非并發(fā)的冪等請求還是得去校驗(yàn)當(dāng)前數(shù)據(jù)的狀態(tài)才行。就拿當(dā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)的時候還是得帶上本身的業(yè)務(wù)狀態(tài)去做校驗(yàn)，select ... for update并非萬能冪等。

5.后端生成token

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

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

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

流程如下：

token機(jī)制

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

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ù)庫悲觀鎖類似，咱們的分布式鎖也只能保證同一個訂單在同一時間的處理。其次也是要去校訂單的狀態(tài)，防止其重復(fù)支付的，也就是說，只要支付的訂單進(jìn)入后端，都要將原先的訂單修改為支付中，防止后續(xù)支付中斷之后的重復(fù)支付。

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

總結(jié)

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

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