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

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

老规矩，背诵版在文末。

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

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

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

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

那么对于 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 cac