查看原文
其他

银行业分布式事务的前世今生

70号实验室 中国金融电脑+ 2022-12-13

9


星期二

2021年2月


验“金”室


事务与金融业务似乎是一对孪生兄弟,想要正确地汇款就不得不采用事务模型,以银行转账的例子来说明事务模式再合适不过了。显然银行业务与事务息息相关,而且传统的集中式部署下的事务也已经有了比较成熟的解决方案。随着互联网时代的到来,分布式、云计算、大数据等新兴技术快速发展,金融产品在当前科技创新的浪潮下也在不断更新,大量业务已经开始向服务化、分布式方向转型,由此带来的分布式事务问题也成为银行技术转型中的重点和难点。


一、传统IT架构下

银行业务分布式事务


分布式事务其实并不是一个新概念或者新问题,传统银行业务也存在分布式事务问题。很多传统银行业务均由大型IBM主机实现,一个主机可以管理多个数据库,比如说,私人账户信息存在一个单独的数据库中,对公账户信息则存在另一个数据库中。这种情况下,如果对公账户需要向私人账户汇款,那么交易涉及两个不同的数据库,如何保证这两个数据库数据的一致性,便是分布式事务所要解决的问题。


那么,银行传统IT架构如何解决分布式事务问题呢?


很显然,需要一个上层的角色来协调各个数据库的状态,这个角色就是事务管理器。除此之外,为了保证数据的一致性,还应将单个操作分为事务的执行和提交或回滚事务两个步骤,具体步骤如图1所示。


图1  两阶段提交协议

第一步

事务管理器向所有事务参与者发送请求,每个事务参与者执行各自的操作并锁定数据库资源,然后将执行结果返回给事务管理器。

第二步

事务管理器收集各个参与者的执行结果。若所有参与者都执行成功,则管理器通知参与者提交事务并释放占用的资源;如果有参与者返回失败或超时,则通知所有参与者回滚事务并释放占用的资源。


这便是两阶段提交协议,著名的XA协议就是基于此两阶段提交协议。正如上文所说,传统的银行系统往往采用IBM大型主机管理多个数据库实现,IBM开发的CICS中间件就提供对XA协议的支持来保证所有数据库的提交或回滚。


二、新形势下银行业务分布式事务


随着需求的快速迭代与业务量的激增,新形势下传统的IBM主机扩容、迭代等遇到挑战。同时随着互联网行业的快速发展,云计算、分布式和微服务技术迅速崛起,银行作为传统金融行业快速拥抱变化,积极地参与到这场IT架构变革中,大量业务不断向服务化、分布式的方向转型。


在分布式系统中,一个大型的主机系统往往被分割为多个子系统。比如上述例子中,对公账户的交易和个人账户的交易可能都在各自系统中,如果有同时涉及这两个账户的交易,那么与同一个主机下操作多个数据库有所不同,这里的交易需要操作多个系统下的数据库。如果仍然采用XA协议,事务管理器需要锁定多个系统下的数据库资源,此时网络的不可靠会成倍增加事务处理时间,产生大量数据库锁和数据不可用。


1.柔性事务与BASE理论

为了解决上述这个问题,业界提出了柔性事务的理念,其基本思想是放宽对强一致性的要求,来换取系统吞吐量的提升,但是分布式系统中所有数据副本在经过一定时间后,最终要能够达到一致的状态。基于此思想,eBay架构师Dan Prichett通过对大规模分布式系统进行实践总结出了BASE理论,即基本可用(Basically Available,分布式系统在遇到故障时,允许损失部分可用性)、软状态(Soft state,允许系统存在中间状态,且此状态不影响系统整体可用性)和最终一致性(Eventually Consistent,分布式系统中所有数据副本在经过一定时间后,最终能够达到一致的状态)。基于上述理论,业界提出SAGA、TCC、消息等新模型解决分布式事务问题。


 2.SAGA模型分布式事务

显然,两阶段提交协议的性能瓶颈在于一阶段对数据库资源的锁定,于是基于柔性事务和BASE理论可以对此进行改造,令每个子事务在执行完事务后立即提交并释放锁资源。那么,当下游交易出现异常时,必须执行其反向交易来保证数据的一致性,这种通过冲正补偿的方式来解决分布式事务的模型一般称为SAGA模型,其基本流程如图2所示。


图2  SAGA模型流程


每个分布式事务有多个参与者,每个参与者都实现其正向交易和反向补偿交易,在业务流程中执行各个参与者的正交易,当出现失败时则补偿前面已完成交易的反交易。


3.TCC模型分布式事务

还是从两阶段提交协议出发,将一阶段对资源的预留从数据库层面上升至业务层面,即通过业务检查而不是锁定数据库来预留资源,这便是TCC模型。TCC即Try、Confirm、Cancel,其基本流程如图3所示。

图3  TCC模型流程

一阶段执行Try:完成所有业务检查,预留必须业务资源;


二阶段执行Confirm:Try阶段成功后执行,不作任何业务检查,执行真正的业务逻辑,且默认Confirm阶段是不会出错的,因此此阶段作业可以异步化实现来提高性能。


二阶段执行Cancel:业务执行失败,需要回滚的情况下执行,释放Try阶段预留的业务资源。


4.消息模型分布式事务

为避免对数据库事务的争用,有时可以将一些同步阻塞的事务操作变为异步的操作,一般称为消息事务模型,该模型的特点是通过异步实现两个系统之间的解耦和并发的缓冲,其基本流程如图4表示。

图4  消息模型流程


 三、分布式事务在银行业务中的运用


随着银行业务不断向服务化、分布式方向转型,分布式事务问题越来越突出。不同的分布式事务模型各有其的特点和适用范围,不同银行业务下的分布式事务问题需要选择合适的事务模型解决。


1. SAGA模式的应用

很明显,由于SAGA正交易完成后子事务立即提交,数据立即可见,在并发场景下SAGA模型无法保证业务的隔离性。而且,对于银行业务的一些场景,比如一借多贷,一笔借款存在多笔贷记子事务,如果前面的子事务资产直接入账,则可能存在交易异常无法回滚的风险。因此,金融核心业务场景如转账汇款、理财购买并不适合使用SAGA模型。但是在银行系统中,SAGA模型适合工作流、业务流等自身隔离性强的业务,比如微黄金新用户开户、凭证式国债挂失销户等。


2. TCC模式的应用

TCC是通过业务的重新编排设计来确保交易数据访问隔离,对业务的改造相对较大,但是因为采用预留数据资源的方式,并不加锁,所以性能较优,且允许和消息模型组合使用。在银行的业务中,一般涉及转账、资金的高风险业务的分布式事务都需要采用TCC模式。


3. 消息模式的应用

消息模式很少单独使用,一般都需要配合SAGA模式或TCC模式使用。典型应用比如说贷款成功后,执行短信通知、优惠券积分等通知辅助类功能的业务以及一些针对外系统的交互。


目前,解决分布式事务问题已经成为银行IT架构转型中必不可少的一环,现阶段,往往是对模型的性能、业务改造成本、可用性等能力上做了针对性的取舍,如何根据自身业务特点探索一套成熟的解决方案,将是未来银行技术转型中的重点。


往期推荐


大资管时代下的智能投顾发展


浅谈分布式系统常用的缓存技术


浅析超宽带技术


浅析日志模式识别技术(Spark)原理


微表情意图识别在银行智慧化金融服务中的应用




您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存