共计 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 中的两阶段提交,有问题欢送留言探讨。