大家好,我是蜗牛哥,跨系统转账网上教程很多,但是都是讲的比较浅,这个功能看似简单,但是细节很多,要做好没那么容易,因为涉及到分布式事务、交易安全性等方面,做不好就出现资损,本文讲一下如何设计一个高可靠跨系统转账,以及要关注的重点
银行A 转账给B银行,银行A进行出金,银行B进行入金
这里只是为了便于理解,所以才把系统命名为银行A/B,具体可能与银行的流程有点细微区别
要根据返回的异常来判断,如果接收到的异常是一个业务异常,并且异常码是双方约定好的,那么可以进行回滚,如果返回的不是一个明确的异常,,那么不能擅自回滚,因为可能是网络超时异常,而网络超时,又分为响应超时和请求超时,如果是响应超时,对方系统可能已经入账了,所以要进行重试操作确认
面试题:超时异常,有哪几种情况,怎么处理?
假如网络超时进行重试,入金方的接口需要支持幂等,否则会出现可能重复入金,而幂等条件是根据出金方的业务流水号+渠道号
进行查询判断
如果失败,那么出金方需要进行解冻回滚操作,如果成功,那么需要进行解冻出金操作。
同时入金方还要设置此组合字段为唯一索引
,这样可以避免重复插入的问题,比如:未查询到数据,则进行插入,正好前面一笔请求事务未提交,如果不设置唯一索引就会导致出现重复插入的问题。
由于这种资产操作非常敏感,稍有失误影响非常大,所以交易安全性是非常重要的,比如:有攻击者知道B银行的入金接口,那么直接调用,他的账户就会加钱。。。,所以要进行以下安全措施
在转账前用私钥对账户进行签名,然后给B银行颁发一个公钥,进行入金的签名验签操作,来保证此请求是正常请求。
为了进一步保证交易的安全性,双方要约定好一个交易的时效性,比如5 分钟,在进行接口调用时携带请求时间,如果这个请求时间是5分钟之前的进行拒绝,等待重新发起。
除了签名,双方系统还要进行对账,而对账又分为总账对账和明细对账
比如查看银行A出金总额是否等于B银行的入金总额,对账频率有小时、天不等,计算公式如下
转账给银行B总额==接收到银行A的入金总额 ?
除了总账要进行核对,明细账也要进行核对,因为总账不平后,要确保那一个账户出现问题,为了实现明细对账双方系统要保留对方系统流水号,这样才能对应起来,对账频率一般是天
在进行账户操作时,要考虑并发问题,进行加锁处理,否则会出现资损,例如
具体可以查看并发扣款,如何保证结果一致性
此表可以进行对账,也可以进行定时任务重新发起重试
- 主键- 流水号- 用户 ID- 方向:转出转入- 金额- 目标方流水号- 时间- 状态 (等待调用、调用成功、调用失败)
此表的作用不用多说,主要说下冻结资金密度,防止真正扣款时账户上没钱,导致交易失败,所以一般都是先进行冻结,如果失败则进行解冻
- 用户 id- 总金额- 冻结资金- 账户状态(正常 冻结)- 时间
记录冻结流水,防止出问题没法追溯
- 主键- 流水号- 用户 Id- 金额- 类型:冻结、解冻- 关联的业务流水号- 时间
以下表为最核心的表,但不是最全的表,比如应该还有账账务流水表、账务订单、热点账户表等
此表可以进行对账,也可以进行定时任务重新发起重试
- 主键- 流水号- 渠道- 业务方流水号 //后期幂等要根据此字段进行判断,所以此字段+渠道号为唯一索引- 用户 ID- 方向:转出转入- 金额- 时间- 状态 (1成功 2失败)
- 用户 id- 总金额- 冻结资金- 账户状态(正常 冻结)- 时间
流程有4个,分别为
其实这也是分布式事务最通用的实现方式,失败就重试,直到最终成功,不管你是 tcc、还是其他的实现方式,只要出现异常,系统最终都要通过定时去重试,直到最终 一致,感兴趣可以去看看 SEATA 源码,遇到异常也是通过定时任务进行重试。
这个流程是定时任务定时发起的,查询小于等于当前时间-指定时间,状态为等待调用的转账记录
并重新发起转账
select * from transfer_list where update_time <= #{queryEndDate}
明细对账,如果数量不大,一天天对没问题,现在银行大多数是基于这种做法,如果文件比较大,可以考虑使用Merkle树,这里就说传统的方式
这种方式最快,数据不大可以这样搞,同时也需要对方系统提供接口支持
这种方式也是比较常用的方式,适合数据量大的对比,一般银行会这么做
以上我们介绍了如何设计一个高可靠的系统转账,可以看到还是比较复杂的,细节很多,主要要考虑补偿、安全、并发扣款几方面,这几方面做好才能设计一个高可靠的系统转账。
本文链接:http://www.28at.com/showinfo-26-61904-0.html高可靠的跨系统转账如何设计
声明:本网页内容旨在传播知识,若有侵权等问题请及时与本网联系,我们将在第一时间删除处理。邮件:2376512515@qq.com
上一篇: Go 内存优化与垃圾收集