AOF的回顾

         回顾Redis 的AOF的持久化机制。 Redis 避免数据丢失的 AOF 方法。这个方法的好处，是每次执行只需要记录操作命令，需要持久化的数据量不大。一般而言，只要你采用的不是 always 的持久化策略，就不会对性能造成太大影响。

        但是，也正因为记录的是操作命令，而不是实际的数据，所以，用 AOF 方法进行故障恢复
的时候，需要逐一把操作日志都执行一遍。如果操作日志非常多，Redis 就会恢复得很缓
慢，影响到正常使用。那这就引出了这篇文章所写的：内存快照。所谓内存快照，就是指内存中的数据在某一个时刻的状态记录。

        对 Redis 来说，它实现类似照片记录效果的方式，就是把某一时刻的状态以文件的形式写
到磁盘上，也就是快照。这样一来，即使宕机，快照文件也不会丢失，数据的可靠性也就
得到了保证。这个快照文件就称为 RDB 文件，其中，RDB 就是 Redis DataBase 的缩
写。

        和 AOF 相比，RDB 记录的是某一时刻的数据，并不是操作，这样恢复数据会很快，那为啥不直接把RDB作为最优选呢？

        我们需要考虑两件事情：

        对哪些数据做快照？这关系到快照的执行效率问题；
        做快照时，数据还能被增删改吗？这关系到 Redis 是否被阻塞，能否同时正常处理请求。

给哪些内存数据做快照？

        Redis 的数据都在内存中，为了提供所有数据的可靠性保证，它执行的是全量快照，也就
是说，把内存中的所有数据都记录到磁盘中，这就类似于给 100 个人拍合影，把每一个人
都拍进照片里。这样做的好处是，一次性记录了所有数据，一个都不少。

        当你给一个人拍照时，只用协调一个人就够了，但是，拍 100 人的大合影，却需要协调
100 个人的位置、状态，等等，这当然会更费时费力。同样，给内存的全量数据做快照，
把它们全部写入磁盘也会花费很多时间。而且，全量数据越多，RDB 文件就越大，往磁盘
上写数据的时间开销就越大。

        对于 Redis 而言，它的单线程模型就决定了，我们要尽量避免所有会阻塞主线程的操作，
所以，针对任何操作，我们都会提一个灵魂之问：“它会阻塞主线程吗?”RDB 文件的生成
是否会阻塞主线程，这就关系到是否会降低 Redis 的性能。

        Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave

        save：在主线程中执行，会导致阻塞；
        bgsave：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是
        Redis RDB 文件生成的默认配置。

好了，这个时候，我们就可以通过 bgsave 命令来执行全量快照，这既提供了数据的可靠
性保证，也避免了对 Redis 的性能影响。

接下来，我们要关注的问题就是，在对内存数据做快照时，这些数据还能“动”吗? 也就是
说，这些数据还能被修改吗？ 这个问题非常重要，这是因为，如果数据能被修改，那就意
味着 Redis 还能正常处理写操作。否则，所有写操作都得等到快照完了才能执行，性能一
下子就降低了。

快照时数据能修改吗?

在给别人拍照时，一旦对方动了，那么这张照片就拍糊了，我们就需要重拍，所以我们当
然希望对方保持不动。对于内存快照而言，我们也不希望数据“动”。

举个例子。我们在时刻 t 给内存做快照，假设内存数据量是 4GB，磁盘的写入带宽是
0.2GB/s，简单来说，至少需要 20s（4/0.2 = 20）才能做完。如果在时刻 t+5s 时，一个
还没有被写入磁盘的内存数据 A，被修改成了 A’，那么就会破坏快照的完整性，因为
A’不是时刻 t 时的状态。因此，和拍照类似，我们在做快照时也不希望数据“动”，也就
是不能被修改。

但是，如果快照执行期间数据不能被修改，是会有潜在问题的。对于刚刚的例子来说，在
做快照的 20s 时间里，如果这 4GB 的数据都不能被修改，Redis 就不能处理对这些数据的
写操作，那无疑就会给业务服务造成巨大的影响。

你可能会想到，可以用 bgsave 避免阻塞啊。这里我就要说到一个常见的误区了，避免阻
塞和正常处理写操作并不是一回事。此时，主线程的确没有阻塞，可以正常接收请求，但
是，为了保证快照完整性，它只能处理读操作，因为不能修改正在执行快照的数据。

为了快照而暂停写操作，肯定是不能接受的。所以这个时候，Redis 就会借助操作系统提
供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，正常处理写操作。

简单来说，bgsave 子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据。
bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。

此时，如果主线程对这些数据也都是读操作（例如图中的键值对 A），那么，主线程和
bgsave 子进程相互不影响。但是，如果主线程要修改一块数据（例如图中的键值对 C），
那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本
数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

 这既保证了快照的完整性，也允许主线程同时对数据进行修改，避免了对正常业务的影
响。

到这里，我们就解决了对“哪些数据做快照”以及“做快照时数据能否修改”这两大问
题：Redis 会使用 bgsave 对当前内存中的所有数据做快照，这个操作是子进程在后台完
成的，这就允许主线程同时可以修改数据。
现在，我们再来看另一个问题：多久做一次快照？我们在拍照的时候，还有项技术叫“连
拍”，可以记录人或物连续多个瞬间的状态。那么，快照也适合“连拍”吗？

可以每秒做一次快照吗？

连拍的间隔比较大的话就是你当及两次拍照的之间发生宕机的话，丢失的数据就会很多。

但是如果连拍间隔非常小的话，虽然 bgsave 执行时不阻塞主线程，但是，如果频繁地执行全量
快照，也会带来两方面的开销。：

一方面，频繁将全量数据写入磁盘，会给磁盘带来很大压力，多个快照竞争有限的磁盘带
宽，前一个快照还没有做完，后一个又开始做了，容易造成恶性循环。

另一方面，bgsave 子进程需要通过 fork 操作从主线程创建出来。虽然，子进程在创建后
不会再阻塞主线程，但是，fork 这个创建过程本身会阻塞主线程，而且主线程的内存越
大，阻塞时间越长。如果频繁 fork 出 bgsave 子进程，这就会频繁阻塞主线程了。那么，
有什么其他好方法吗？

此时，我们可以做增量快照，所谓增量快照，就是指，做了一次全量快照后，后续的快照
只对修改的数据进行快照记录，这样可以避免每次全量快照的开销

在第一次做完全量快照后，T1 和 T2 时刻如果再做快照，我们只需要将被修改的数据写入
快照文件就行。但是，这么做的前提是，我们需要记住哪些数据被修改了。你可不要小瞧
这个“记住”功能，它需要我们使用额外的元数据信息去记录哪些数据被修改了，这会带
来额外的空间开销问题。如下图所示：

 但是我们两次拍照之间有1万键值对别更改了。但是存出这个增量的空间很有效。所以这个增量的只适用于修改次数少的。

到这里，你可以发现，虽然跟 AOF 相比，快照的恢复速度快，但是，快照的频率不好把
握，如果频率太低，两次快照间一旦宕机，就可能有比较多的数据丢失。如果频率太高，
又会产生额外开销，那么，还有什么方法既能利用 RDB 的快速恢复，又能以较小的开销做
到尽量少丢数据呢

AOF和RDB混合使用

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一
定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF
日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出
现文件过大的情况了，也可以避免重写开销。

如下图所示，T1 和 T2 时刻的修改，用 AOF 日志记录，等到第二次做全量快照时，就可
以清空 AOF 日志，因为此时的修改都已经记录到快照中了，恢复时就不再用日志了。

 这个方法既能享受到 RDB 文件快速恢复的好处，又能享受到 AOF 只记录操作命令的简单
优势，颇有点“鱼和熊掌可以兼得”的感觉。