在業務開發中,我們常常會面對防止重複請求的問題。當服務端對於請求的回應涉及資料的修改,或狀態的變更時,可能會造成極大的危害。重複請求的後果在交易系統、售後維權,以及支付系統中尤其嚴重。
前台操作的抖動,快速操作,網路通訊或後端回應慢,都會增加後端重複處理的機率。前台操作去抖動和防快速操作的措施,我們首先會想到在前端做一層控制。當前端觸發操作時,或彈出確認介面,或disable入口並倒數計時等等,此處不細表。但前端的限制僅能解決少部分問題,且不夠徹底,後端自有的防重複處理措施必不可少,義不容辭。
在介面實作中,我們常要求介面要滿足冪等性,來確保多次重複請求時只有一次有效。
查詢類別的介面幾乎總是冪等的,但在包含諸如資料插入,多模組資料更新時,達到冪等性會比較難,尤其是高並發時的冪等性要求。例如第三方支付前台回調和後台回調,第三方支付批量回調,慢性能業務邏輯(如用戶提交退款申請,商家同意退貨/退款等)或慢網絡環境時,是重複處理的高發場景。
這裡針對「使用者提交退款申請」的例子,說明一下嘗試過的防重複處理方法的效果。後端防重複處理的方式,我們先後嘗試了三種:
這種方式簡單直觀,從DB查詢出來的退款詳情(包括狀態)往往還可以用在後續邏輯中,沒有花額外的工作專門處理重複請求的問題。
這種查詢狀態後進行驗證的邏輯,從程式碼上線後就一直存在於所有含狀態的業務邏輯處理中,必不可少。但對於防重複處理效果並不好:在前端添加防重複提交前,每週平均在25筆;前端優化後,每週降到7筆。這個數量佔總退款申請數的3%%,一個仍無法接受的比例。
理論上,任意次請求只要在資料狀態更新之前都完成了查詢操作,則業務邏輯的重複處理就會發生。如下圖所示。最佳化的方向是減少查詢到更新之間業務處理時間,可降低空檔期的同時影響。極致情況下如果查詢和更新變成了原子操作,則不存在我們目前的問題。
Redis儲存查詢輕量快速。在request進來的時候,可以先記錄在快取中。後續進來的request每次進行驗證。整個流程處理完成,清除快取。以退款為範例:
#與1)的發放相比,資料庫換成回應更快的快取。但仍然不是原子操作。插入和讀取快取還是有時間間隔。在極致的情況下還是有重複操作的情況。此方法優化後,每週1筆重複操作。
需要原子性操作,想到了資料庫的唯一索引。新建一個TradeLock表:
CREATE TABLE `TradeLock` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `type` int(11) NOT NULL COMMENT '锁类型', `lockId` int(11) NOT NULL DEFAULT '0' COMMENT '业务ID', `status` int(11) NOT NULL DEFAULT '0' COMMENT '锁状态', PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='Trade锁机制';
● 每次request進來則往表裡面插入資料:
成功,则可以继续操作(相当于获取锁); 失败,则说明有操作在进行。
● 操作完成後,刪除此筆記錄。 (相當於釋放鎖)。
目前已經上線,等待下週的數據統計。
由於資料庫的操作比較消耗性能,了解到redis的計數器也是原子性操作。果斷採用計數器。既可以提高效能,還不用存儲,而且能提升qps的峰值。
還是以訂單退款為例子:
● 每次request進來則新建一個以orderId為key的計數器,然後+1。
如果>1(不能获得锁): 说明有操作在进行,删除。 如果=1(获得锁): 可以操作。
● 操作結束(刪除鎖定):刪除這個計數器。
要了解计数器,可以参考:http://www.redis.cn/commands/incr.html#
PHP语言自身没有提供进程互斥和锁定机制。因此才有了我们上面的尝试。网上也有文件锁机制,但是考虑到我们的分布式部署,建议还是用缓存。在大并发的情况下,程序各种情况的发生。特别是涉及到金额操作,不能有一分一毫的差距。所以在大并发要互斥的情况下可以考虑3、4两种方案。
爱迪生尝试了1600多种材料选择了钨丝发明了灯泡,实践出真知。遇到问题,和问题斗争,最后解决问题是一个最大提升自我的过程,不但加宽自己的知识广度,更加深了自己的技能深度。达到目标之后的成就感更是不言而喻。
以上是防訂單重複提交策略方法的詳細內容。更多資訊請關注PHP中文網其他相關文章!