[发明专利]分布式事务处理方法及装置

说明书

本发明提供了一种分布式事务处理方法及装置。该方法包括：请求全局事务管理器记录事务的全局事务信息，并获取全局事务管理器返回的全局事务唯一标识；执行全局事务中所有事务分支操作；如果全局事务任意一个事务分支执行失败，请求全局事务管理器进行全局事务回滚；如果全局事务所有事务分支对应的本地事务都提交成功，请求全局事务管理器进行全局事务提交。本发明提供的分布式事务处理方法及装置能够在保持对业务无侵入、只需要数据库支持本地事务的情况下保证分布式系统的事务一致性。

技术领域

本发明涉及分布式系统技术领域，特别是涉及一种分布式事务处理方法及装置。

背景技术

随着分布式技术在银行交易系统的逐渐使用，不可避免的会出现一个交易需要跨多个数据库或者跨多个子系统(微服务)并保证事务的情况。由于这些资源在物理上是完全独立的，所以要保证分布式下事务的原子性、一致性、隔离性以及持久性的控制就变得非常复杂。

举例来说，假设有一个交易为A给B转账200元，大致流程如下：

1)交易开始

2)调用转出服务，A转出200元；

3)调用转入服务，B转入200元；

4)交易结束

在分布式系统中，转入、转出服务可能位于不同的进程；或者A、B账户位于不同的数据库。并且每个步骤都有失败或异常的可能。这种情况下数据库自身的本地事务无法保证上述的两个步骤全部成功或全部失败。

业内目前现有的解决分布式事务问题的方案有：XA两阶段提交协议(2PC)，TCC(Try-Confirm-Cancel)等。

XA两阶段提交协议：基于2PC的分布式事务处理过程如下：在第一阶段，事务协调节点向所有事务参与者发送“准备”请求，如果所有事务参与者均返回“准备成功”，则在第二阶段，协调节点向所有参与者发送“提交”请求。各参与者在接收到上述“提交”请求之后，执行相应的数据处理子操作。如果在第一阶段，有任一参与者返回“准备失败”,则协调节点向所有参与者发送“回滚”请求。

TCC(Try-Confirm-Cancel)：TCC方案在服务层实现两阶段协议，将一个完整的流程从业务上划分为两个阶段。第一阶段(Try)进行对应的合法性检查以及为事务执行预留所需的资源，确保第二阶段能够执行成功。事务中所有的第一阶段执行成功后，在进入第二阶段提交(Confirm)阶段，使用使用预留的资源进行正式的业务操作；如果第一阶段执行出现异常等需要回滚分布式事务，则进行第二阶段回滚(Cancel)阶段，将预留的资源解除预留。

针对上述两种分布式解决方案分析如下：

XA两阶段提交协议：

1)XA两阶段提交协议是一种阻塞协议，在业务执行以及提交的第一阶段需要等待最慢的一个事务分支完成。在此期间所有参与者一直占用系统资源，如锁资源、数据库连接资源等，导致系统资源的浪费，进而影响整体性能，无法实现高性能的分布式事务处理。

2)需要数据库支持XA协议，并且性能与保证度都依赖于数据库的实现。例如MySQL从5.0开始部分支持XA协议，但在一定场景下，MySQL的XA事务处理存在数据不一致的风险。

3)目前基于XA的分布式解决方案，大都依托于重量级的应用服务器(Tuxedo/WebLogic/WebSphere等)，不适用于微服务架构

TCC(Try-Confirm-Cancel)：

1)对业务系统侵入性大，业务需要按Try、Confirm、Cancel进行开发，成本较高；

资源预留不易处理，需要根据业务特征设计，处理不当难以保证一致性，或降低系统性能，当业务需求发生变更时难以及时响应变化。对业务开发人员的设计能力要求较高。