共计 2851 个字符，预计需要花费 8 分钟才能阅读完成。
@[toc]
为什么要两阶段提交？一阶段提交不行吗？
小伙伴们晓得，MySQL 中的事务是两阶段提交，咱们见到的很多分布式事务也都是两阶段提交的，例如 Seata，那么为什么要两阶段提交呢？一次间接提交了不行吗？明天咱们来聊聊这个话题。
对于分布式事务 seata，不懂的小伙伴能够参考松哥之前的文章，传送门：
- 五分钟带你体验一把分布式事务！so easy！
- 看了那么多博客，还是不懂 TCC，无妨看看这个案例！
- XA 事务水很深，小伙子我怕你把握不住！
- 你这 Saga 事务保“隔离性”吗？
1. 什么是两阶段提交
1.1 binlog 与 redolog
binlog
binlog 咱们中文个别称作归档日志，如果大家看过松哥之前发的 MySQL 主从搭建，应该对这个日志有印象，当咱们搭建 MySQL 主从的时候就离不开 binlog（传送门：MySQL8 主从复制踩坑指南）。
binlog 是 MySQL Server 层的日志，而不是存储引擎自带的日志，它记录了所有的 DDL 和 DML(不蕴含数据查问语句)语句，而且是以事件模式记录，还蕴含语句所执行的耗费的工夫等，须要留神的是：
- binlog 是一种逻辑日志，他里边所记录的是一条 SQL 语句的原始逻辑，例如给某一个字段 +1，留神这个区别于 redo log 的物理日志（在某个数据页上做了什么批改）。
- binlog 文件写满后，会主动切换到下一个日志文件持续写，而不会笼罩以前的日志，这个也区别于 redo log，redo log 是循环写入的，即前面写入的可能会笼罩后面写入的。
- 一般来说，咱们在配置 binlog 的时候，能够指定 binlog 文件的有效期，这样在到期后，日志文件会主动删除，这样防止占用较多存储空间。
依据 MySQL 官网文档的介绍，开启 binlog 之后，大略会有 1% 的性能损耗，不过这还是能够承受的，一般来说，binlog 有两个重要的应用场景：
- MySQL 主从复制时：在主机上开启 binlog，主机将 binlog 同步给从机，从机通过 binlog 来同步数据，进而实现主机和从机的数据同步。
- MySQL 数据恢复，通过应用 mysqlbinlog 工具再联合 binlog 文件，能够将数据恢复到过来的某一时刻。
redo log
后面咱们说的 binlog 是 MySQL 本人提供的，在 MySQL 的 server 层，而 redo log 则不是 MySQL 提供的，是存储引擎 InnoDB 本人提供的。所以在 MySQL 中就存在两类日志 binlog 和 redo log，存在两类日志既有历史起因（InnoDB 最早不是 MySQL 官网存储引擎）也有技术起因，这个咱们当前再细聊。
咱们都晓得，事务的四大个性外面有一个是持久性，即只有事务提交胜利，那么对数据库做的批改就被永恒保留下来了，写到磁盘中了，怎么做到的呢？其实咱们很容易想到是在每次事务提交的时候，将该事务波及批改的数据页全副刷新到磁盘中，一旦写到磁盘中，就不怕数据失落了。
然而要是每次都这么搞，数据库就不晓得慢到哪里去了！因为 Innodb 是以页为单位进行磁盘交互的，而一个事务很可能只批改一个数据页外面的几个字节，这个时候将残缺的数据页刷到磁盘的话，不仅效率低，也浪费资源。效率低是因为这些数据页在物理上并不间断，将数据页刷到磁盘会波及到随机 IO。
有鉴于此，MySQL 设计了 redo log，在 redo log 中只记录事务对数据页做了哪些批改。那有人说，写 redo log 不就是磁盘 IO 吗？而写数据到磁盘也是磁盘 IO，既然都是磁盘 IO，那干嘛不把间接把数据写到磁盘呢？还费这事！
此言差矣。
写 redo log 跟写数据有一个很大的差别，那就是 redo log 是程序 IO，而写数据波及到随机 IO，写数据须要寻址，找到对应的地位，而后更新 / 增加 / 删除，而写 redo log 则是在一个固定的地位循环写入，是程序 IO，所以速度要高于写数据。
redo log 自身又分为：
- 日志缓冲（redo log buffer)，该局部日志是易失性的。
- 重做日志(redo log file)，这是磁盘上的日志文件，该局部日志是长久的。
MySQL 每执行一条 DML 语句，先将记录写入 redo log buffer，后续在某个工夫点再一次性将多个操作记录写到 redo log file，这种先写日志再写磁盘的技术就是 MySQL 里常常说到的 WAL(Write-Ahead Logging) 技术（预写日志）。
1.2 两阶段提交
在 MySQL 中，两阶段提交的配角就是 binlog 和 redolog，咱们来看一个两阶段提交的流程图：
从上图中能够看出，在最初提交事务的时候，有 3 个步骤：
- 写入 redo log，处于 prepare 状态。
- 写 binlog。
- 批改 redo log 状态变为 commit。
因为 redo log 的提交分为 prepare 和 commit 两个阶段，所以称之为两阶段提交。
2. 为什么须要两阶段提交
如果没有两阶段提交，那么 binlog 和 redolog 的提交，无非就是两种模式：
- 先写 binlog 再写 redolog。
- 先写 redolog 再写 binlog。
这两种状况咱们别离来看。
假如咱们要向表中插入一条记录 R，如果是先写 binlog 再写 redolog，那么假如 binlog 写完后解体了，此时 redolog 还没写。那么重启复原的时候就会出问题：binlog 中曾经有 R 的记录了，当从机从主机同步数据的时候或者咱们应用 binlog 复原数据的时候，就会同步到 R 这条记录；然而 redolog 中没有对于 R 的记录，所以解体复原之后，插入 R 记录的这个事务是有效的，即数据库中没有该行记录，这就造成了数据不统一。
相同，假如咱们要向表中插入一条记录 R，如果是先写 redolog 再写 binlog，那么假如 redolog 写完后解体了，此时 binlog 还没写。那么重启复原的时候也会出问题：redolog 中曾经有 R 的记录了，所以解体复原之后，插入 R 记录的这个事务是无效的，通过该记录将数据恢复到数据库中；然而 binlog 中还没有对于 R 的记录，所以当从机从主机同步数据的时候或者咱们应用 binlog 复原数据的时候，就不会同步到 R 这条记录，这就造成了数据不统一。
那么依照后面说的两阶段提交就能解决问题吗？
咱们来看如下三种状况：
状况一：一阶段提交之后解体了，即 写入 redo log，处于 prepare 状态 的时候解体了，此时：
因为 binlog 还没写，redo log 处于 prepare 状态还没提交，所以解体复原的时候，这个事务会回滚，此时 binlog 还没写，所以也不会传到备库。
状况二：假如写完 binlog 之后解体了，此时：
redolog 中的日志是不残缺的，处于 prepare 状态，还没有提交，那么复原的时候，首先查看 binlog 中的事务是否存在并且残缺，如果存在且残缺，则间接提交事务，如果不存在或者不残缺，则回滚事务。
状况三：假如 redolog 处于 commit 状态的时候解体了，那么重启后的解决计划同状况二。
由此可见，两阶段提交可能确保数据的一致性。
3. 小结
好啦，明天和小伙伴们简略聊了一下 MySQL 中的两阶段提交，有问题欢送留言探讨。