聊聊 MySQL 事务二阶段提交

回想当年，高并发还没有这么普遍，分布式也没有这么流行。

初次接触二阶段提交，源于想以事务的方式实现对 MongoDB 中多个集合数据的修改，而 MongoDB 本身不支持事务，官方推荐的方案就是使用二阶段提交。

MySQL 和事务早已成为工作中不可或缺的一部分，随着分布式的流行，二阶段提交出现在视野中的次数也越来越多。

然而，MySQL、事务、二阶段提交这 3 个名词组合在一起成为一个整体，从第一次接触到现在也不过一年时间。

第一次接触到 MySQL 事务二阶段提交这个概念时，心里还有点小激动。

因为当年研究 MongoDB 二阶段提交，其实是没有弄明白的。

没想到，多年以后，在 MySQL 中发现了二阶段提交的身影，心头似乎涌现出了那种感觉：众里寻 TA 千百度，蓦然回首，那人却在灯火阑珊处。

本文我们就一起来看看 MySQL 事务是怎么实现二阶段提交的。

本文内容基于 MySQL 8.0.29 源码。

正文

1、什么是二阶段提交？

二阶段提交是一种用于保证分布式事务原子性的协议。

二阶段提交的实现过程，有 2 个角色参与其中：

资源管理器，Resource Manager，负责管理一部分资源。对于数据库来说，这里的资源指的就是数据。

如果把分布式事务看成是一个整体，每个资源管理器会负责其中的一部分，也就是分布式事务的一个本地事务。

资源管理器在分布式事务中的角色就是干活的，所以，我们可以称它为执行器。

事务管理器，Transaction Manager，负责管理分布式事务，协调事务的提交、回滚、以及崩溃恢复。

事务管理器在分布式事务中，就是那个总揽全局、指挥资源管理器干活的角色，所以，我们可以称它为协调器。

二阶段提交，顾名思义，会包含 2 个阶段：

prepare 阶段，协调器会询问所有执行器，是否可以提交事务。

此时，各个本地事务实际上已经执行完成，数据写入已经成功，就差提交这最后一哆嗦了。

如果有任何一个执行器因为它所执行的本地事务有问题不能提交，分布式事务就不能提交，协调器会通知所有执行器进行回滚操作。

如果每一个执行器都回复协调器可以提交，分布式事务就会进入下一个阶段，也就是 commit 阶段。

commit 阶段，协调器会通知执行器进行提交操作。

执行器收到提交通知之后，各自提交自己的本地事务。

所有执行器都提交完成之后，二阶段提交就结束了，分布式事务也就执行完成了。

以上只介绍了二阶段提交的正常流程，实际上二阶段提交的复杂之处在于异常流程处理，对二阶段提交完整流程感兴趣的小伙伴，可以自行查找相关资料。

2、MySQL 二阶段提交场景

在 MySQL 中，二阶段提交有 4 种使用场景：

场景 1，外部 XA 事务，数据库中间件、应用程序作为协调器，MySQL 数据库实例作为执行器。

XA 事务也就是分布式事务。其它支持分布式事务的数据库实例，如 Oracle、SQL Server，也可以和 MySQL 一起作为执行器。

这种场景下，MySQL 通过以下 XA 系列命令来实现二阶段提交：

• XA START xid，开启分布式事务。
• XA END xid，标识分布式事务中的 SQL 都已经执行完成。
• XA PREPARE xid，执行分布式事务提交的 prepare 阶段。
• XA COMMIT xid，执行分布式事务提交的 commit 阶段。
• XA ROLLBACK xid，回滚分布式事务。

以上命令具体怎么使用，可以参照官方文档的 XA Transactions 小节，链接：https://dev.mysql.com/doc/refman/8.0/en/xa.html

场景 2，单个 MySQL 实例的内部 XA 事务，没有开启 binlog 日志，SQL 语句涉及多个支持事务的存储引擎。

TC_LOG_MMAP 类对象作为协调器，多个支持事务的存储引擎作为执行器。

TC_LOG_MMAP 会打开一个名为 tc.log 的磁盘文件，并通过 MMAP 映射到内存中，用于记录分布式事务的 xid。

场景 3，单个 MySQL 实例的内部 XA 事务，没有开启 binlog 日志，SQL 语句只涉及 1 个支持事务的