第三方支付同步和異步回調併發數據一致性的問題
在第三方交易系統中的支付場景下，一般的步驟是，用戶在系統產生訂單，支付系統向第三方發起支付請求創建支付訂單，用戶跳轉至第三方系統進行支付，支付完成後會產生 同步回調 和 異步回調。系統一般根據 第三方異步回調 來確認本次交易結果
特殊業務場景
由於目前存在特殊的業務場景，本次交易結果必須依賴前端的 同步回調 請求來決定用戶是否能進入下一步的產品交付場景。簡單來說，在特殊的業務場景下，必須依賴 同步回調 的結果來判定本次交易狀態
併發一致性問題
當同步回調和異步回調同時發生的時候，由於實現細節的不同，兩個流程需要將訂單狀態分別流轉到不同的狀態，由於查詢數據庫使用的是快照讀，在某一個流程中修改狀態的事務未提交的時候，查詢到這條記錄一樣的事務提交之前的狀態，所以會存在數據沒有被流轉到正確的處理狀態
原因
在 A B 事務併發的情況下，A B 兩個事務都依賴同一行數據中數據字段的狀態進行下一步的操作，當 A 事務決定將狀態更新到 x 時的事務還未提交的時候，B 查詢到的數據狀態和 A 事務是相同的，導致 B 事務會將數據字段更新到 y 導致數據結果和預期不一致
解決方式
-
事務 + 當前讀
保證兩個業務的查詢，更新都在一個事務中，且使用當前讀查詢數據的最新狀態 -
利用分佈式鎖串行化接口
由於業務強依賴同步回調，所以將同步回調與異步回調串行，使同步回調保持在異步回調之前，異步回調在同步回調請求未產生之前不進行處理
第三方異步回調返回問題
由於第三方依賴異步回調的結果來分析我方業務是否正常，如果在異步場景下直接返回異常那麼在第三方的業務系統中會存在大量錯誤，這是我們不希望看到的。
由於不強依賴第三方的異步回調，系統可以使用消息中間件將回調消息收取，返回第三方正常，利用消息 + Job 腳本的方式對數據沒有正常流轉的訂單進行補償重試