第三方支付異步通知的陷阱

版權聲明：本文為博主原創文章，未經博主允許不得轉載。 https://blog.csdn.net/j16421881/article/details/78703792

??用戶下單后調用第三方支付付款，然后接收第三方支付的異步通知，以便確認支付是否成功。
如下圖

??但異步通知可能由于網絡原因，或者應用服務崩潰沒有接收到。為了應對這種情況需要后臺創建一個定時任務去調用第三方接口，主動查詢支付結果。這種情形下就涉及并發的問題，可能后臺定時任務跟異步通知同時收到了支付成功結果，同時對響應數據進行處理。通常通過加鎖來避免這種問題。
??到了這里一切看起來很美好。代碼提交后在測試環境順利通過。由于測試環境情形單一，測試用例不夠，異步通知總是成功的，做為備用手段的后臺定時任務沒有被測試覆蓋到就進入了生產環境。后臺定時任務的邏輯有可能是錯的，而由于生產環境配置了負載平衡，保證了高可用，直到很久都不會發現定時任務的錯誤。筆者就遇到過在長達一年的時間里定時任務從來就不起作用。
??所以開發要在qa階段跟測試人員緊密配合，保證每個測試用例都覆蓋到，比如關掉異步通知服務，看定時任務是否能正確處理。直到有一天我發現其他部門一位同事采用了一個很有創意的做法，既然異步通知不靠譜，干脆就不要，完全靠后臺定時任務主動查詢第三方支付結果，然后進一步處理。