第三方支付异步通知的陷阱
生活随笔
收集整理的這篇文章主要介紹了
第三方支付异步通知的陷阱
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
版權聲明:本文為博主原創文章,未經博主允許不得轉載。 https://blog.csdn.net/j16421881/article/details/78703792
??用戶下單后調用第三方支付付款,然后接收第三方支付的異步通知,以便確認支付是否成功。
如下圖
??但異步通知可能由于網絡原因,或者應用服務崩潰沒有接收到。為了應對這種情況需要后臺創建一個定時任務去調用第三方接口,主動查詢支付結果。這種情形下就涉及并發的問題,可能后臺定時任務跟異步通知同時收到了支付成功結果,同時對響應數據進行處理。通常通過加鎖來避免這種問題。
??到了這里一切看起來很美好。代碼提交后在測試環境順利通過。由于測試環境情形單一,測試用例不夠,異步通知總是成功的,做為備用手段的后臺定時任務沒有被測試覆蓋到就進入了生產環境。后臺定時任務的邏輯有可能是錯的,而由于生產環境配置了負載平衡,保證了高可用,直到很久都不會發現定時任務的錯誤。筆者就遇到過在長達一年的時間里定時任務從來就不起作用。
??所以開發要在qa階段跟測試人員緊密配合,保證每個測試用例都覆蓋到,比如關掉異步通知服務,看定時任務是否能正確處理。直到有一天我發現其他部門一位同事采用了一個很有創意的做法,既然異步通知不靠譜,干脆就不要,完全靠后臺定時任務主動查詢第三方支付結果,然后進一步處理。
總結
以上是生活随笔為你收集整理的第三方支付异步通知的陷阱的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: R升级和包更新
- 下一篇: 中国HBase技术社区第五届MeetUp