跨行转账系统设计详解
跨行转账系统设计详解
假设张三在A银行向B银行的李四进行转账:
然而,转账过程远比简单的消息发送和接收复杂得多。为了确保交易的安全性和可靠性,我们需要考虑以下几个关键问题:
一、安全性
如果有人恶意获取了B银行的收款接口,不断给李四账户充值,这显然是非法行为。为了防止此类风险,我们可以采取以下安全措施:
解决方式:
- 签名机制:发送方(付款方)使用自己的私钥对转账相关信息(如转账金额、收款方账号、转账时间等)进行加密生成签名。接收方(收款方或银行等金融机构)可以使用发送方的公钥来验证签名,只有用对应的私钥生成的签名才能被公钥正确验证。
二、转账失败处理
转账失败可能发生在多个环节:
发送消息前:
- 账户信息错误:包括但不限于收款方账号有误,收款方户名和账号不匹配,开户行和账号不匹配等。
- 银行系统故障:银行内部的转账系统可能会出现软件或硬件故障。例如,服务器维护、网络问题、软件升级等情况可能导致转账功能暂时无法使用或者转账过程中断。在这种情况下,已经发起的转账可能会失败。
- 支付清算系统故障:跨行转账需要通过支付清算系统进行资金划转。如果支付清算系统(如中国的大小额支付系统、SWIFT 国际汇款系统等)出现故障,比如网络拥堵、系统崩溃等情况,会影响转账的正常进行,导致转账失败。
- 安全验证:密码错误,短信验证码错误,风险评估未通过(如果转账金额过大、交易时间异常、转账对象可疑等因素综合起来导致交易风险过高,且转账方无法满足额外的风险验证要求(如提供更详细的身份信息、资金来源证明等))。
- 转账金额限制:银行或支付平台为了控制风险,会对转账金额设置一定的限制。例如,个人网上银行每日转账限额为 5 万元,如果转账金额超过这个限额,转账就会失败,除非转账方通过其他方式(如到银行柜台办理)提高转账限额。
- 转账次数限制:部分银行或支付平台还会限制转账次数。比如,一张银行卡在一天内最多只能进行 10 次转账操作,如果超过这个次数,后续的转账请求将被拒绝。
发送消息时网络超时:
如果在发送消息给B银行时发生超时,A银行可以向B银行查询是否收到该入账请求。如果确定B银行已经收到请求,可以继续等待响应结果。如果A银行确定转账请求没有成功发送给B银行,并且经过风险评估后认为可以重新发送,那么可以重新发送入账请求。但在重新发送之前,需要确保该笔转账不会被重复处理,这可能需要引入幂等性机制。如果不能重发,A银行撤销扣账,响应失败给用户。
响应超时:
如果A银行消息已经发送成功,但是在规定的响应时间内迟迟未收到响应,此时B银行可能已经收到入账请求,可能已经入账成功也可能还未入账或入账失败。A银行可以向B银行查询入账请求响应结果。
响应失败:
如果B银行已经收到入账请求,但是因为B银行的各种原因导致入账失败,A银行收到响应失败时,也应该扣账失败。
三、幂等性
幂等性是指对同一操作的多次重复执行所产生的影响均与一次执行的结果相同。也就是说,无论一个操作被执行多少次,系统的状态改变效果是一样的。
在转账系统中,如果由于网络故障、用户误操作或者系统重试机制等原因导致转账操作可能被多次执行,幂等性可以确保资金不会被重复转出。
解决方式:
- 使用唯一交易标识(如交易流水号):记录和检查转账的状态。如果流水号查询到记录,返回交易结果;如果查询不到记录,则进行转账然后再响应交易结果。
四、并发控制
多个转账操作可能同时访问和修改账户余额等关键数据,如果没有适当的控制机制,可能会导致数据不一致。
例如,两个并发的转账操作,A银行张三余额有100元,同时发起转账a和b两个交易,a和b同时读取余额有100元,a交易扣款90,b交易扣款80,假如先执行了a交易,账户余额修改变成10,b交易修改余额为20,最终为20元,则不正确。
解决方式:
数据库事务隔离级别:“可串行化(Serializable)” 隔离级别是最高的隔离级别,它能保证并发执行的事务的结果与它们串行执行的结果相同,有效地避免了数据不一致和顺序问题。在这种隔离级别下,数据库会通过加锁等机制来确保事务之间的隔离。例如把查询账户余额,冻结账户余额中的相应转账金额,放在同一个事务中。
消息队列:将转账请求放入消息队列,消费者按照消息队列的顺序依次处理转账请求。这样可以避免并发转账带来的冲突。消息队列可以保证消息的顺序性和可靠性,例如 RabbitMQ、Kafka 等消息队列。
五、冲正机制
如果转账请求已经从付款方账户扣除了资金,但在向收款方账户入账时失败,这时就需要进行冲正操作,将已经扣除的资金退回到付款方账户,使双方账户的余额恢复到交易前的状态。
总结
跨行转账系统设计需要综合考虑交易检查、并发控制、交易安全等多个方面。通过引入签名机制、幂等性设计、并发控制和冲正机制等技术手段,可以确保转账过程的安全性和可靠性。