資金損耗是如何產生的？
支付系統對技術的考量有兩點：
1、技術對提供服務的穩定性
2、資損的避免
這類問題通常只會導致系統使用慢，用戶體驗不好和投訴的情況
由於人為操作不當或者系統邏輯錯誤導致的資金損失，這都屬於資金損失。
這時候通知了商戶系統支付成功了，那商戶發貨了就會導致資金損失。
可能引發資金損失的技術問題：
1、網絡異常問題：
接口一旦發生網絡異常，這時候支付系統並沒有達到最終狀態，
網絡異常會走Exception的catch處理，catch一般會走失敗分支。
但銀行側最終的狀態可能是成功、失敗或者處理中，
如果銀行側最終成功，但商戶側被告知是失敗，這樣商戶就會再次發起支付，就可能造成了重複付款。
修正方案，當用到網絡支付的異常返回時，將訂單設置為處理中的狀態，然後等待定時查詢或者通知，來返回最終狀態即可。
2、查詢和通知問題：
支付接口一般包括了交易接口、主動查詢接口和異步通知接口。
查詢接口一是用來查詢非實時返回最終狀態的訂單結果，二是用來核對查詢，
第一種查詢失敗或者查詢異常，並不代表最終交易狀態就是失敗的，特別是第三方交易接口，這個查詢失敗指的是查詢本身失敗而並不是交易失敗。
第二種查詢速度過快，比如支付5秒之後立即去查詢，但是沒有此訂單，可能是支付系統的處理鏈路較長，建議過一會再查詢或者支付後立即發起查詢的時間間隔設置遠一些。
3、接口冪等問題：
接口可能隔天返回的狀態不同，
當無法保證別人系統健壯性的問題，那麼就保證自己系統健壯性。
上游訂單流水號作為唯一索引做冪等，比如接口請求沒有響應，以唯一訂單流水號再次發起請求重試。
這樣既保證了安全，又滿足了繼續發起請求的流程。
前後通知不一致的問題，如果第一次通知是準確的，就以第一次為主，如果第二次狀態不一致，那麼就進行人工預警，人為干預。 否則容易發生重複發起的情況
4、狀態同步問題：
4、併發問題：
併發導致的重複支付
定時器問題，可能某時刻任務阻塞，兩次任務造成了併發。這種情況需要控制定時器的任務狀態，
還可以控制狀態機來控制任務的狀態
重試問題：
各種重試機制導致的重複支付，
比如MQ，Nginx，Http都有重試機制，
各種中間件的retry機制都會導致訂單重複支付，
防止這種情況可以用到，前後端防重，
前端，JS禁掉提交按鈕
後端，數據庫加索引，redis加鎖，token校驗等等
後端最簡單的方式:數據庫樂觀鎖 + 有限狀態機 + 白名單
狀態機，有限個狀態之間的轉移和動作等行為的數學模型，狀態的管理和狀態的驅動。
支付系統中，狀態的流轉控制，可以避免訂單被錯誤的執行或重複執行，
比如成功的狀態不允許變更為處理中，
已發送的狀態不允許被再撿起支付等
事後止損：實時監控系統
閱讀更多 老曹漫談 的文章
