防重复请求处理的实践与总结
#防重復處理總結
##背景
在業務開發中，我們常會面對防止重復請求的問題。當服務端對于請求的響應涉及數據的修改，或狀態的變更時，可能會造成極大的危害。重復請求的后果在交易系統、售后維權，以及支付系統中尤其嚴重。
前臺操作的抖動，快速操作，網絡通信或者后端響應慢，都會增加后端重復處理的概率。
前臺操作去抖動和防快速操作的措施，我們首先會想到在前端做一層控制。當前端觸發操作時，或彈出確認界面，或disable入口并倒計時等等，此處不細表。
但前端的限制僅能解決少部分問題，且不夠徹底，后端自有的防重復處理措施必不可少，義不容辭。
在接口實現中，我們常要求接口要滿足冪等性，來保證多次重復請求時只有一次有效。
查詢類的接口幾乎總是冪等的，但在包含諸如數據插入，多模塊數據更新時，達到冪等性會比較難，尤其是高并發時的冪等性要求。比如第三方支付前臺回調和后臺回調，第三方支付批量回調，慢性能業務邏輯（如用戶提交退款申請，商家同意退貨/退款等）或慢網絡環境時，是重復處理的高發場景。
##嘗試
這里針對“用戶提交退款申請”的例子，說明一下嘗試過的防重復處理方法的效果。
后端防重復處理的方式，我們先后嘗試了三種：
####1）基于DB中退款訂單狀態的驗證
這種方式簡單直觀，從DB查詢出來的退款詳情（包括狀態）往往還可以用在后續邏輯中，沒有花額外的工作專門應對重復請求的問題。
這種查詢狀態后進行驗證的邏輯，從代碼上線后就一直存在于所有含狀態的業務邏輯處理中，必不可少。但對于防重復處理效果并不好：在前端添加防重復提交前，每周平均在25筆；前端優化后，每周降到7筆。這個數量占總退款申請數的3%%，一個仍然無法接受的比例。
理論上，任意次請求只要在數據狀態更新之前都完成了查詢操作，則業務邏輯的重復處理就會發生。如下圖所示。優化的方向是減少查詢到更新之間業務處理時間，可降低空檔期的并發影響。極致情況下如果查詢和更新變成了原子操作，則就不存在我們當前的問題。
####2）基于緩存數據狀態的驗證
Redis存儲查詢輕量快速。在request進來的時候，可以先記錄在緩存中。后續進來的request每次進行驗證。整個流程處理完成，清除緩存。以退款為例子：
與1）的發放相比，數據庫換成響應更快的緩存。但是仍然不是原子操作。插入和讀取緩存還是有時間間隔。在極致的情況下還是存在重復操作的情況。
此方法優化后，每周1筆重復操作。
####3）利用唯一索引機制的驗證
需要原子性操作，想到了數據庫的唯一索引。
新建一個TradeLock表：
每次request進來則往表里面插入數據：
——成功,則可以繼續操作（相當于獲取鎖）； ——失敗,則說明有操作在進行。 操作完成后，刪除此條記錄。（相當于釋放鎖）
目前已經上線，等待下周的數據統計。
####4）基于緩存的計數器驗證：
由于數據庫的操作比較消耗性能，了解到redis的計數器也是原子性操作。果斷采用計數器。既可以提高性能，還不用存儲，而且能提升qps的峰值。
還是以訂單退款為例子：
每次request進來則新建一個以orderId為key的計數器，然后＋1。
如果>1（不能獲得鎖）: 說明有操作在進行，刪除。如果=1（獲得鎖）: 可以操作。 操作結束（刪除鎖）：刪除這個計數器。
要了解計數器，可以參考：
link
##總結：
PHP語言自身沒有提供進程互斥和鎖定機制。因此才有了我們上面的嘗試。
網上也有文件鎖機制，但是考慮到我們的分布式部署，建議還是用緩存。
在大并發的情況下，程序各種情況的發生。特別是涉及到金額操作，不能有一分一毫的差距。所以在大并發要互斥的情況下可以考慮3、4兩種方案。
愛迪生嘗試了1600多種材料選擇了鎢絲發明了燈泡，實踐出真知。遇到問題，和問題斗爭，最后解決問題是一個最大提升自我的過程，不但加寬自己的知識廣度，更加深了自己的技能深度。達到目標之后的成就感更是不言而喻。
總結
以上是生活随笔為你收集整理的防重复请求处理的实践与总结的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Java使用简单工厂模式对面向接口编程模
- 下一篇： 设计模式之反射与配置文件