字节一面：事务还没提交的时候，redolog 能不能被持久化到磁盘？

r囧r小猫 2023-09-28 10:24 5阅读 0赞

又是被自己菜醒的一天，总结面经看到这题目听都没听过，打开百度就像吃饭一样自然

> 老规矩，背诵版在文末。点击阅读原文可以直达我收录整理的各大厂面试真题

首先，咱需要明白的是，啥是持久化？

听起来高大上，换句简单的话来说，就是把数据写到磁盘上，也成为**落盘**。

那为啥要做持久化到磁盘？

目的就是可以在数据丢失后进行恢复，保证数据不丢失。

**那么对于 MySQL 来说，只要 binlog 和 redolog 都能正确持久化到磁盘上，就可以保证数据不丢失了**。

由此引出问题，不过在讲 redolog 之前，我们还是有必要先来说一下 binlog 的持久化操作。

## binlog 持久化 ##

这里引入了一个新的概念：binlog cache

从名字就能看出来，binlog cache 其实就是一片内存区域，充当缓存的作用。

每个线程都有自己 binlog cache 区域，**在事务运行的过程中，MySQL 会先把日志写到 binlog cache 中，等到事务真正提交的时候，再统一把 binlog cache 中的数据写到 binlog 文件中**。（binlog cache 有很多个，binlog 文件只有一个！）

事实上，这个从 binlog cache 写到 binlog 文件中的操作，并**不**就是落盘操作了，这里仅仅是把 binlog 到了文件系统的 page cache 上（这一步对应下图中的 write 操作）。

> 简单解释下文件系统的功能 page cache：
> 
> CPU 如果要访问外部磁盘上的文件，需要首先将这些文件的内容拷贝到内存中，由于硬件的限制，从磁盘到内存的数据传输速度是很慢的，如果现在物理内存有空余，干嘛不用这些空闲内存来缓存一些磁盘的文件内容呢，**这部分用作缓存磁盘文件的内存就叫做 page cache**。
> 
> 很多同学看到这里可能觉得特别特别熟悉，是的，和 CPU 里面的高速缓存是不是很像？两者其实都是利用的局部性原理，只不过**高速缓存是 CPU 缓存内存的数据，而 page cache 是内存缓存磁盘的数据**，这也体现了操作系统内存层次结构分级的思想。

所以，最后需要把握 page cache 中间的数据同步到磁盘上，才算真正完成了 binlog 持久化（这一步对应下图中的 fsync 操作）。一般情况下，我们认为 fsync 才占磁盘的 IOPS (Input/Output Operations Per Second)

![ed4795525f498dad64ecad893aa91186.png][]

write 和 fsync 的时机，是由参数决定 sync\_binlog 控制的：

*  sync\_binlog = 0，每次提交事务的时候，只进行一次 write，不进行 fsync
 *  sync\_binlog = 1后，每次提交事务的时候，执行 write 和 fsync
 *  sync\_binlog = N(N>1)，每次提交事务的时候，执行 write，累积 N 个事务后再执行 fsync

可以看出来，如果业务场景涉及到的 IO 操作很多的话，可以适当增大 sync\_binlog 的值，提高性能。但是也存在一定的风险，比如你设置成 100，万一在第 80 这些事务提交的时候数据库宕机了，那这些事务的 binlog 日志由于没有执行 fsync，也就丢失了。

## redolog 持久化 ##

类比 binlog，在事务执行过程中，binlog 都是存在 binlog cache 中，redolog 也有这样一块内存区域，叫作 **redolog buffer**。

**在事务运行的过程中，MySQL 会先把日志写到 redolog buffer 中，等到事务真正提交的时候，再统一把 redolog buffer 中的数据写到 redolog 文件中**。和 binlog 的落盘操作一样，这个从 redolog buffer 写到 redolog 文件中的操作，并**不**就是落盘操作了，这里仅仅是把 redolog 到了文件系统的 page cache 上，最后还需要执行 fsync 才能够实现真正的落盘。

![8ea9ee15409f145e4c1cce2b842dfd58.png][]

解释下 redo log buffer？

在一个事务的更新过程中，日志是要写很多次的。比如下面这个事务：

begin;
      insert into table1 ...
      insert into table2 ...
     commit;

这个事务要往两个方向表 table1 和 table2 中插入记录，为了确保这个事务不被拆开，一次性地完整写入日志文件中，在插入数据的过程中，我们需要把生成的日志都先保存起来。redolog buffer 就是这么一个用来先存 redo 日志的地方。

也就是说，在执行第一条 insert 语句的时候，redolog buffer 也就写入了这条记录的日志。

不同于 binlog cache 每个线程都有一个，redolog buffer 只有那么一个。

事实上，日志写到 redolog buffer 是很快的，wirte 到 page cache 也差不多，但是 fsync 持久化到磁盘的速度就慢多了，为了控制速度 redo log 的写入策略，InnoDB 提供了 innodb\_flush\_log\_at\_trx\_commit 参数，它有三种可能取值：

*  innodb\_flush\_log\_at\_trx\_commit = 0，每次事务提交的时候，都只是把 redolog 留在 redolog buffer 中
 *  innodb\_flush\_log\_at\_trx\_commit = 1，每次事务提交的时候，都执行 fsync 将 redolog 直接持久化到磁盘
 *  innodb\_flush\_log\_at\_trx\_commit = 2，每次事务提交的时候，都只执行 write 将 redolog 写到文件系统的 page cache 中

说了这么多，各位小伙伴们对 binlog 和 redolog 的持久化机制想必都有所了解了，我们来看文题：**事务还没提交的时候，redolog 能不能被持久化到磁盘呢**？

先说答案，答案就是**有可能**。

分析下 redolog 可能存在的三种状态（binlog 也差不多）：

*  事务执行过程中，存在 MySQL 的进程内存中的 redolog buffer 中
 *  事务提交，执行 write 操作存在文件系统的 page cache 中，但是没有执行 fsync 操作持久化到磁盘
 *  事务提交，执行 fsync 操作持久化到磁盘

至于为什么说事务还没提交的时候，redolog 也有可能被持久化到磁盘呢？

InnoDB 有一个后台线程，每隔 1 秒轮询一次，具体的操作是这样的：调用 write 将 redolog buffer 中的日志写到文件系统的 page cache，然后调用 fsync 持久化到磁盘。而在事务执行中间过程的 redolog 都是直接写在 redolog buffer 中的，也就是说，一个没有提交的事务的 redolog，也是有可能会被后台线程一起持久化到磁盘的。

另外，除了后台线程每秒一次的轮询操作外，还有两种场景会让一个没有提交的事务的 redolog 写盘：

1.  innodb\_flush\_log\_at\_trx\_commit 设置是 1，这样并行的某个事务提交的时候，就会顺带将这个事务的 redolog buffer 持久化到磁盘举个例子，假设事务 A 执行到一半，已经写了一些 redolog 到 redolog buffer 中，这时候有另外一个事务 B 提交，按照 innodb\_flush\_log\_at\_trx\_commit = 1 的逻辑，事务 B 要把 redolog buffer 里的日志全部持久化到磁盘，这时候，就会带上事务 A 在 redolog buffer 里的日志一起持久化到磁盘
2.  redo log buffer 占用的空间达到 redolo buffer 大小（由参数 innodb\_log\_buffer\_size 控制，默认是 8MB）一半的时候，后台线程会主动写盘。不过由于这个事务并没有提交，所以这个写盘动作只是 write 到了文件系统的 page cache，仍然是在内存中，并没有调用 fsync 真正落盘

--------------------

最后放上这道题的背诵版：

> **面试官**：
> 
> 问题：事务还没提交的时候，redo log 能不能被持久化到磁盘呢？
> 
> 相关问题：MySQL 是如何保证数据不丢失的呢？
> 
> **小牛肉**：事务还没有提交的时候，redo log 是有可能被持久化到磁盘的。
> 
> redolog 的具体落盘操作是这样的：在事务运行的过程中，MySQL 会先把日志写到 redolog buffer 中，等到事务真正提交的时候，再统一把 redolog buffer 中的数据写到 redolog 文件中。不过这个从 redolog buffer 写到 redolog 文件中的操作也就是 write 并不就是落盘操作了，这里仅仅是把 redolog 写到了文件系统的 page cache 上，最后还需要执行 fsync 才能够实现真正的落盘。
> 
> 也就是说，redolog 其实存在三种状态：
> 
> 事务执行过程中，存在 MySQL 的进程内存中的 redolog buffer 中
> 
> 事务提交，执行 write 操作存在文件系统的 page cache 中，但是没有执行 fsync 操作持久化到磁盘
> 
> 事务提交，执行 fsync 操作持久化到磁盘
> 
> 额为什么说事务还没提交的时候，redolog 也有可能被持久化到磁盘呢？
> 
> 主要有三种可能的原因：
> 
> 第一种情况：InnoDB 有一个后台线程，每隔 1 秒轮询一次，具体的操作是这样的：调用 write 将 redolog buffer 中的日志写到文件系统的 page cache，然后调用 fsync 持久化到磁盘。而在事务执行中间过程的 redolog 都是直接写在 redolog buffer 中的，也就是说，一个没有提交的事务的 redolog，也是有可能会被后台线程一起持久化到磁盘的。
> 
> 第二种情况：  
> innodb\_flush\_log\_at\_trx\_commit 设置是 1，这个参数的意思就是，每次事务提交的时候，都执行 fsync 将 redolog 直接持久化到磁盘（还有 0 和 2 的选择，0 表示每次事务提交的时候，都只是把 redolog 留在 redolog buffer 中；2 表示每次事务提交的时候，都只执行 write 将 redolog 写到文件系统的 page cache 中）。举个例子，假设事务 A 执行到一半，已经写了一些 redolog 到 redolog buffer 中，这时候有另外一个事务 B 提交，按照 innodb\_flush\_log\_at\_trx\_commit = 1 的逻辑，事务 B 要把 redolog buffer 里的日志全部持久化到磁盘，这时候，就会带上事务 A 在 redolog buffer 里的日志一起持久化到磁盘
> 
> 第二种情况：redo log buffer 占用的空间达到 redolo buffer 大小（由参数 innodb\_log\_buffer\_size 控制，默认是 8MB）一半的时候，后台线程会主动写盘。不过由于这个事务并没有提交，所以这个写盘动作只是 write 到了文件系统的 page cache，仍然是在内存中，并没有调用 fsync 真正落盘

![686705de662e4fe89b3b1d3bcc2489bc.jpeg][]

[ed4795525f498dad64ecad893aa91186.png]: https://img-blog.csdnimg.cn/img_convert/ed4795525f498dad64ecad893aa91186.png
[8ea9ee15409f145e4c1cce2b842dfd58.png]: https://img-blog.csdnimg.cn/img_convert/8ea9ee15409f145e4c1cce2b842dfd58.png
[686705de662e4fe89b3b1d3bcc2489bc.jpeg]: https://img-blog.csdnimg.cn/686705de662e4fe89b3b1d3bcc2489bc.jpeg