聊聊 MySQL 事务二阶段提交
发布时间：2022-08-02 11:16:10 所属栏目：云计算 来源：互联网
导读：回想当年，高并发还没有这么普遍，分布式也没有这么流行。 初次接触二阶段提交，源于想以事务的方式实现对 MongoDB 中多个集合数据的修改，而 MongoDB 本身不支持事务，官方推荐的方案就是使用二阶段提交。 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 个支持事务的存储引擎。 这种场景下，原本是不需要二阶段提交的，但是为了统一，还是会以二阶段提交的结构进行提交操作。 TC_LOG_DUMMY 类对象作为协调器，不记录 xid，存储引擎作为执行器。 从 DUMMY 可以看出，TC_LOG_DUMMY 是个伪装的协调器。 场景 4，单个 MySQL 实例的内部 XA 事务，开启了 binlog 日志，SQL 语句涉及 1 个或多个支持事务的存储引擎。 MYSQL_BIN_LOG 类对象作为协调器，分布式事务的 xid 记录在 binlog 日志文件中。binlog 日志和存储引擎作为执行器。 binlog 日志和存储引擎都是独立单元，为了保证多个存储引擎之间、存储引擎和 binlog 日志之间的数据一致性，在事务提交时，这些操作要么都提交，要么都回滚，需要借助 XA 事务实现。 InnoDB 是 MySQL 最常用的存储引擎，为了支持主从架构，binlog 日志也是必须要开启的，这是 MySQL 最常使用的场景。 接下来我们就以 InnoDB 存储引擎 + binlog 日志为例，来介绍 MySQL 内部 XA 事务的二阶段提交过程 3、prepare 阶段 来到 prepare 阶段之前，InnoDB 对表中数据的写操作都已经完成，就差提交或者回滚这最后一哆嗦了。 prepare 阶段，binlog 日志和 InnoDB 主要干的事情有这些： 图片 prepare 阶段，binlog 日志没有什么需要做的，InnoDB 主要做的事情就是修改事务和 undo 段的状态，以及记录 xid（分布式事务的 ID）。 InnoDB 会把内存中事务对象的状态修改为 TRX_STATE_PREPARED，把事务对应 undo 段在内存中的对象状态修改为 TRX_UNDO_PREPARED。 修改完内存中各对象的状态，还不算完事，还要把事务对应 undo 段的段头页中 Undo Segment Header 的 TRX_UNDO_STATE 字段值修改为 TRX_UNDO_PREPARED。 然后，把 xid 信息写入当前事务对应日志组的 Undo Log Header 中的 xid 区域。 修改 TRX_UNDO_STATE 字段值、写 xid，这两个操作都要修改 undo 页，修改 undo 页之前会先记录 Redo 日志。 4、commit 阶段 （1）commit 阶段整体介绍 到了 commit 阶段，一个事务就已经接近尾声了。 写操作（包括增、删、改）已经完成，内存中的事务状态已经修改，undo 段的状态也已经修改，xid 信息也已经写入 Undo Log Header，prepare 阶段产生的 Redo 日志已经写入到 Redo 日志文件。 由于 log_flusher 线程会每秒进行刷盘操作，此时，事务产生的 Redo 日志有可能已经刷新到磁盘了，也有可能还停留在 Redo 日志文件的操作系统缓冲区中。 剩余的收尾工作，包括： Redo 日志刷盘。 事务的 binlog 日志从临时存放点拷贝到 binlog 日志文件。 binlog 日志文件刷盘。 InnoDB 事务提交。 为了保证主从数据一致性，同一个事务中，上面列出的收尾工作必须串行执行。 Redo & binlog 日志刷盘都涉及到磁盘 IO，如果每提交一个事务，都把该事务中的 Redo 日志、binlog 日志刷盘，会涉及到很多小数据量的 IO 操作，频繁的小数量 IO 操作非常消耗磁盘的读写性能。 为了提升磁盘 IO 效率，从而提高事务的提交效率，MySQL 从 5.6 开始引入了 binlog 日志组提交功能，5.7 中把原本在 prepare 阶段进行的 Redo 日志刷盘操作迁移到了 commit 阶段。 binlog 日志组提交有何神奇之处，怎么就能提升磁盘 IO 效率呢？ 引入 binlog 日志组提交功能之后，commit 阶段细分为 3 个子阶段。 对于每个子阶段，都可以有多个事务处于该子阶段，写日志 & 刷盘操作可以合并： flush 子阶段，Redo 日志可以一起刷盘，binlog 日志不需要加锁就可以一起写入 binlog 日志文件。 sync 子阶段，binlog 日志可以一起刷盘。 commit 子阶段，Redo 日志可以一起刷盘。 通过合并 Redo 日志刷盘操作、合并 binlog 日志写入日志文件操作、合并 binlog 日志刷盘操作，把小数据量多次 IO 变为大数据量更少次数 IO，可以提升磁盘 IO 效率。 （编辑：岳阳站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
