二阶段提交的核心逻辑是把多个事务的 Redo 日志合并刷盘,把多个事务的 binlog 日志合并刷盘,从而把少量数据多次 IO 变为更大数据更少 IO,最终达到提升事务提交效率的目标。
回想当年,高并发还没有这么普遍,分布式也没有这么流行。
初次接触二阶段提交,源于想以事务的方式实现对 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 个支持事务的存储引擎。
这种场景下,原本是不需要二阶段提交的,但是为了统一,还是会以二阶段提交的结构进行提交操作。