高可靠的跨系統轉賬如何設計
大家好,我是蝸牛哥,跨系統轉賬網上教程很多,但是都是講的比較淺,這個功能看似簡單,但是細節很多,要做好沒那么容易,因為涉及到分布式事務、交易安全性等方面,做不好就出現資損,本文講一下如何設計一個高可靠跨系統轉賬,以及要關注的重點
示例說明
銀行A 轉賬給B銀行,銀行A進行出金,銀行B進行入金
這里只是為了便于理解,所以才把系統命名為銀行A/B,具體可能與銀行的流程有點細微區別
會遇到哪些問題?
轉賬失敗,不能直接回滾
要根據返回的異常來判斷,如果接收到的異常是一個業務異常,并且異常碼是雙方約定好的,那么可以進行回滾,如果返回的不是一個明確的異常,,那么不能擅自回滾,因為可能是網絡超時異常,而網絡超時,又分為響應超時和請求超時,如果是響應超時,對方系統可能已經入賬了,所以要進行重試操作確認
面試題:超時異常,有哪幾種情況,怎么處理?
系統重試要保持冪等
假如網絡超時進行重試,入金方的接口需要支持冪等,否則會出現可能重復入金,而冪等條件是根據出金方的業務流水號+渠道號
進行查詢判斷
- 如果有記錄,并根據狀態,來決定響應結果
- 如果沒有記錄則進行入金,在返回對應的響應結果
如果失敗,那么出金方需要進行解凍回滾操作,如果成功,那么需要進行解凍出金操作。
同時入金方還要設置此組合字段為唯一索引
,這樣可以避免重復插入的問題,比如:未查詢到數據,則進行插入,正好前面一筆請求事務未提交,如果不設置唯一索引就會導致出現重復插入的問題。
交易安全性
由于這種資產操作非常敏感,稍有失誤影響非常大,所以交易安全性是非常重要的,比如:有攻擊者知道B銀行的入金接口,那么直接調用,他的賬戶就會加錢。。。,所以要進行以下安全措施
要進行簽名調用
在轉賬前用私鑰對賬戶進行簽名,然后給B銀行頒發一個公鑰,進行入金的簽名驗簽操作,來保證此請求是正常請求。
要對交易的時效性進行校驗
為了進一步保證交易的安全性,雙方要約定好一個交易的時效性,比如5 分鐘,在進行接口調用時攜帶請求時間,如果這個請求時間是5分鐘之前的進行拒絕,等待重新發起。
要進行系統對賬
除了簽名,雙方系統還要進行對賬,而對賬又分為總賬對賬和明細對賬
總賬對賬
比如查看銀行A出金總額是否等于B銀行的入金總額,對賬頻率有小時、天不等,計算公式如下
轉賬給銀行B總額==接收到銀行A的入金總額 ?
明細對賬
除了總賬要進行核對,明細賬也要進行核對,因為總賬不平后,要確保那一個賬戶出現問題,為了實現明細對賬雙方系統要保留對方系統流水號,這樣才能對應起來,對賬頻率一般是天
要考慮并發扣款
在進行賬戶操作時,要考慮并發問題,進行加鎖處理,否則會出現資損,例如
- 訂單a和訂單 b同一時間都查詢到了,賬戶余額為1000
- 訂單a扣款200,訂單b扣款 100
- 假如訂單 a先執行,那么賬戶余額為800,訂單 b 修改為賬戶余額為900,最終為 900,反正則為 800,都不對
具體可以查看并發扣款,如何保證結果一致性
涉及到表可能有哪些?
出金方
轉賬流水表
此表可以進行對賬,也可以進行定時任務重新發起重試
- 主鍵
- 流水號
- 用戶 ID
- 方向:轉出轉入
- 金額
- 目標方流水號
- 時間
- 狀態 (等待調用、調用成功、調用失敗)
賬戶表
此表的作用不用多說,主要說下凍結資金密度,防止真正扣款時賬戶上沒錢,導致交易失敗,所以一般都是先進行凍結,如果失敗則進行解凍
- 用戶 id
- 總金額
- 凍結資金
- 賬戶狀態(正常 凍結)
- 時間
凍結記錄表
記錄凍結流水,防止出問題沒法追溯
- 主鍵
- 流水號
- 用戶 Id
- 金額
- 類型:凍結、解凍
- 關聯的業務流水號
- 時間
入金方
以下表為最核心的表,但不是最全的表,比如應該還有賬賬務流水表、賬務訂單、熱點賬戶表等
渠道轉賬流水表
此表可以進行對賬,也可以進行定時任務重新發起重試
- 主鍵
- 流水號
- 渠道
- 業務方流水號 //后期冪等要根據此字段進行判斷,所以此字段+渠道號為唯一索引
- 用戶 ID
- 方向:轉出轉入
- 金額
- 時間
- 狀態 (1成功 2失敗)
賬務表
- 用戶 id
- 總金額
- 凍結資金
- 賬戶狀態(正常 凍結)
- 時間
最終流程應該是什么樣的?
流程有4個,分別為
- 正常的轉賬流程
- 補償轉賬流程
- 總賬對賬流程
- 明細對賬流程
其實這也是分布式事務最通用的實現方式,失敗就重試,直到最終成功,不管你是 tcc、還是其他的實現方式,只要出現異常,系統最終都要通過定時去重試,直到最終 一致,感興趣可以去看看 SEATA 源碼,遇到異常也是通過定時任務進行重試。
轉賬流程
轉賬補償流程
這個流程是定時任務定時發起的,查詢小于等于當前時間-指定時間,狀態為等待調用的轉賬記錄
并重新發起轉賬
select * from transfer_list where update_time <= #{queryEndDate}
總賬對賬流程
明細對賬流程
明細對賬,如果數量不大,一天天對沒問題,現在銀行大多數是基于這種做法,如果文件比較大,可以考慮使用Merkle樹,這里就說傳統的方式
直接查詢對比
這種方式最快,數據不大可以這樣搞,同時也需要對方系統提供接口支持
基于文件對比
這種方式也是比較常用的方式,適合數據量大的對比,一般銀行會這么做
總結
以上我們介紹了如何設計一個高可靠的系統轉賬,可以看到還是比較復雜的,細節很多,主要要考慮補償、安全、并發扣款幾方面,這幾方面做好才能設計一個高可靠的系統轉賬。