轉載至我的博客https://www.infrastack.cn ，公眾號：架構成長指南

大家好，我是蝸牛哥，跨系統轉賬網上教程很多，但是都是講的比較淺，這個功能看似簡單，但是細節很多，要做好沒那么容易，因為涉及到分布式事務、交易安全性等方面，做不好就出現資損，本文講一下如何設計一個高可靠跨系統轉賬，以及要關注的重點

示例說明

假設有用戶 A在 銀行A 轉賬給B銀行的用戶B 100 元

這里只是為了便于理解，所以才把系統命名為銀行A/B，具體可能與銀行的流程有點細微區別

會遇到哪些問題？

轉賬失敗，不能直接回滾

要根據返回的異常來判斷，如果接收到的異常是一個業務異常，并且異常碼是雙方約定好的，那么可以進行回滾，如果返回的不是一個明確的異常，，那么不能擅自回滾，因為可能是網絡超時異常，而網絡超時，又分為響應超時和請求超時，如果是響應超時，對方系統可能已經入賬了，所以要進行重試操作確認

面試題：超時異常，有哪幾種情況，怎么處理？

系統重試要保持冪等

假如網絡超時進行重試，入金方的接口需要支持冪等，否則會出現可能重復入金，而冪等條件是根據出金方的業務流水號+渠道號進行查詢判斷

1. 如果有記錄，并根據狀態，來決定響應結果
2. 如果沒有記錄則進行入金，在返回對應的響應結果

如果失敗，那么出金方需要進行解凍回滾操作，如果成功，那么需要進行解凍出金操作。

同時入金方還要設置此組合字段為唯一索引，這樣可以避免重復插入的問題，比如：未查詢到數據，則進行插入，正好前面一筆請求事務未提交，如果不設置唯一索引就會導致出現重復插入的問題。

交易安全性

由于這種資產操作非常敏感，稍有失誤影響非常大，所以交易安全性是非常重要的，比如：有攻擊者知道B銀行的入金接口，那么直接調用，他的賬戶就會加錢。。。，所以要進行以下安全措施

要進行簽名調用

在轉賬前用私鑰對賬戶進行簽名，然后給B銀行頒發一個公鑰，進行入金的簽名驗簽操作，來保證此請求是正常請求。

要對交易的時效性進行校驗

為了進一步保證交易的安全性，雙方要約定好一個交易的時效性，比如5 分鐘，在進行接口調用時攜帶請求時間，如果這個請求時間是5分鐘之前的進行拒絕，等待重新發起。

要進行系統對賬

除了簽名，雙方系統還要進行對賬，而對賬又分為總賬對賬和明細對賬

總賬對賬

比如查看銀行A出金總額是否等于B銀行的入金總額，對賬頻率有小時、天不等，計算公式如下

轉賬給銀行B總額==接收到銀行A的入金總額 ？

明細對賬

除了總賬要進行核對，明細賬也要進行核對，因為總賬不平后，要確保那一個賬戶出現問題，為了實現明細對賬雙方系統要保留對方系統流水號，這樣才能對應起來，對賬頻率一般是天

要考慮并發扣款

在進行賬戶操作時，要考慮并發問題，進行加鎖處理，否則會出現資損，例如

1. 訂單a和訂單 b同一時間都查詢到了，賬戶余額為1000
2. 訂單a扣款200，訂單b扣款 100
3. 假如訂單 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樹，這里就說傳統的方式

直接查詢對比

這種方式最快，數據不大可以這樣搞，同時也需要對方系統提供接口支持

基于文件對比

這種方式也是比較常用的方式，適合數據量大的對比，一般銀行會這么做

總結

以上我們介紹了如何設計一個高可靠的系統轉賬，可以看到還是比較復雜的，細節很多，主要要考慮補償、安全、并發扣款幾方面，這幾方面做好才能設計一個高可靠的系統轉賬。

掃描下面的二維碼關注我的微信公眾帳號，在微信公眾帳號中回復?加群?即可加入到我們的技術討論群里面共同學習。

總結

以上是生活随笔為你收集整理的在分布式事务场景下，如何设计一个高可靠的跨系统转账的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。