责编 | 仲培艺

　　对于分布式数据库而言，分布式事务控制是重点和难点，一直以来没有成熟的方案可以突破CAP理论，几乎每个分布式数据库研发团队都在分布式事务控制方案上结合了各自应用特点，进行了针对性的取舍，可以说是八仙过海各显神通。以下是我对分布式事务控制的理解：

　　分布式事务控制的最终目标是实现一致性，方案大体分为实时一致性和最终一致性两种。两阶段提交是比较典型的实时一致性方案，提供补偿事务和基于消息队列的异步处理方案是最终一致性方案。两阶段提交由于同步阻塞、存在脏读可能性等问题，在某些银行的应用场景下无法使用，如果将隔离级别修改为串行化则可以解决脏读问题，但对性能影响较大。基于消息队列的异步处理方案将事务拆分成多个本地子事务，子事务之间通过消息队列衔接，实现串行执行，单个子事务占用资源的时间很短，并发度高。但这种最终一致性方案如果应用到银行的应用中势必影响用户体验，而且对应用侵略性较大，实施成本高。

　　在分析了以上事务处理方案的优缺点之后，根据银行业务对实时一致性的要求，考虑到用户体验和实施成本的影响，我们提出了基于全局事务ID（Global transaction ID，以下简称GTID）的分布式事务解决方案。

　　基本原理

　　在基于GTID的分布式事务方案（以下简称本方案）中，我们把协调参与者和记录全局事务状态这两个功能分开，用计算节点协调各事务参与者进行事务操作，全局事务管理器仅管理全局事务的状态。为了确保事务状态正常，全局事务管理采用了实时持久化和实时同步到备机等多重保障机制。本方案事务管理架构如图1所示。

　　图1 基于GTID的分布式事务管理方案

　　两（三）阶段提交的核心思想是通过前期的多次准备和协调工作，尽可能让最后的提交操作能够成功。而本方案认为大部分事务都可以一次提交成功，因此采用一阶段提交+补偿事务的方式，如果事务在提交阶段有部分节点提交失败，本方案将回滚已成功提交的事务，而不是让失败的节点不断重试。与两（三）阶段提交相比，本方案在大部分情况下减少了与数据节点的交互次数，降低了锁冲突概率，提升了事务处理效率。

　　建表时增加一个隐藏字段，用于记录GTID。

　　每个事务开始时为其申请一个GTID，该GTID是全局唯一且单调递增的，GTID申请成功后，我们称该GTID为活跃（Active）状态，对应该GTID的事务状态为未提交状态，若涉及到数据更新，则将GTID更新到本事务将要更新的数据中，事务成功提交后，将GTID释放，此时我们称GTID为非活跃（UnActive）状态，对应的事务状态为已提交状态。

　　当事务提交失败时，提交失败节点会自动回滚，对于已成功提交的节点，需要将其回滚，数据恢复到更新前的状态，全部节点回滚完成后，同样需要将GTID释放。

　　事务的原子性

　　保证事务的原子性是分布式事物的最大难点，在分布式环境下，保证事务原子性主要有两种方案，一种是在提交命令发出后不回滚，尽可能保证提交成功；另一种是在提交命令发出后，根据响应结果判断是提交成功还是该进行回滚。

　　我们采用的是第二种方式，由于我们的方案采用的是普通事务的提交方式，目前的主流数据库在本地事务提交后都不能回滚，我们必须自己实现已提交事务的回滚。已提交事务回滚架构如图2所示。

　　图2 已提交事务回滚示意图

　　在每个数据节点上部署一个回滚模块用于已提交事务回滚，当部分数据节点提交失败时，计算节点向已经提交成功的数据库节点的回滚模块发送已提交事务回滚命令，命令中包含事务对应的GTID，回滚模块根据GTID进行回滚，步骤如下：

定位：根据GTID相关信息定位要进行分析的数据库日志文件列表；

查询：遍历数据库日志文件，找到GTID对应的事务日志块；

分析：分析日志块，为事务中每条SQL语句生成反向SQL语句；

执行回滚：将所有反向SQL语句逆序执行，并保证在一个事务中。

　　由于该回滚操作不是数据库原生回滚机制，在实际使用中需要经过大量优化才能保证回滚的性能达到可用级别。

　　事务的一致性