分布式事务处理两阶段提交机制和原理

一、背景

笔者在上篇文章中回顾了经典的两阶段提交算法原理及缺陷，有兴趣可点击查看原文《「技术讨论」经典的两阶段提交算法原理及缺陷》，此篇不做详述。

为避免经典的两阶段提交算法缺陷的发生，昆仑分布式数据库的分布式事务处理机制基于经典的两阶段提交算法，并在此基础上增强了其容灾能力和错误处理能力。

故此可以做到任意时刻昆仑数据库集群的任意节点宕机或者网络故障、超时等都不会导致集群管理的数据发生不一致或者丢失等错误。

二、昆仑数据库如何分布式事务处理两阶段提交？

昆仑数据库分布式事务处理功能涉及的模块分布在计算节点，存储集群和元数据集群和cluster_mgr模块中（如图1）。

2.1 计算节点模块

计算节点包含全局事务管理器（Global Transaction Manager，GTM），它掌握着一个计算节点中正在运行的每一个客户端连接（即Session，会话）中正在执行的分布式事务GT的内部状态，关键信息包括事务GT读写了哪些存储集群（storage shard)，以及全局事务ID等。

下图（如图1）中的GT1，GT2内部状态为：

• GT1在存储集群1上执行的事务分支T11做了读写操作，在存储集群2上执行的事务分支T12做了写入操作。

• GT2在存储集群1上执行的事务分支T21做了只读操作，在存储集群2上执行的事务分支T22做了写入操作。

计算节点的GTSS后台进程负责成组批量写入全局事务的commit log日志到元数据集群中。

昆仑数据库会确保每一个记录了Commit log的全局事务GT，都一定会完成提交。具体的两阶段提交流程见下文详述，本节先把相关模块介绍完。

2.2 元数据集群模块

元数据集群也是一个高可用的MySQL 集群，它的commit log记录着每一个两阶段提交的事务的提交决定。

这些提交决定是给cluster_mgr做错误处理使用的，实际生产系统场景下极少会真的用到，但是其信息非常关键。

只有当计算节点或者存储节点发生宕机、断电等故障和问题时，才会被cluster_mgr用来处理残留的prepared状态的事务分支。

2.3 存储集群模块

存储集群是一个MySQL在存储集群中，mysql的会话（THD）对象内部，包含分布式事务分支（简称XA事务）的状态：

• 在下图（如图1）中存储节点1包含分布式事务GT1的事务分支GT1.T11和GT2的事务分支GT2.T21的本地执行状态。