你了解 Redis RDB 快照吗

前言

我们都知道，Redis 有两大持久化机制：AOF 日志和 RDB 快照。AOF 方法每次执行只记录命令，持久化的数据量不大。但是在 AOF 日志恢复时，需要把日志的每条命令都执行一遍。如果日志很多，恢复过程就会变得很漫长。因此，Redis 提供了另一种持久化机制，那就是 RDB 快照。

RDB 快照写入规则

和 AOF 记录命令不同，RDB 记录的当前的数据。Redis 有提供 2 个命令来生成 RDB 快照文件，分别是 save 和 bgsave。

• save: 这种方式在主线程执行，容易导致阻塞；

• bgsave: 创建一个子进程来执行 RDB 写入工作。这种方式可避免主线程的阻塞（默认配置）

这里你可能有疑问，快照过程中，如果有数据做了修改，RDB 是怎么做的呢？这里就要介绍下写时复制了。

写时复制技术

写时复制是操作系统提供的功能，Redis 在执行 RDB 快照时，依然能正常处理写操作。这样说可能不够明朗，详细点说说 bgsave 这个过程：

bgsave 子进程是由主线程 fork 生成的，而且可以共享主线程的所有内存数据。主线程和子进程 bgsave 是互不干扰的。

当主线程要修改一块数据，这块数据就会复制一份到副本上，然后主线程在这个副本上修改。同时呢，bgsave 子进程可继续将原来的数据写入 RDB 文件。这样就能某时刻快照的完整性，也不影响 redis 同时对当时数据的操作。

写到这，你是否认为 RDB 快照这样设计就完美了呢？答案是否定的。我们仔细想想，如果每次快照都是将全量数据备份，数据量大了之后，会有什么后果：

• 全量数据写入 RDB 文件，磁盘压力增大。可能存在前一个快照没执行完，后一个又开始了。

• bgsave 子进程虽不阻塞主线程，但它是由主线程 fork 出来的。fork 的过程是会阻塞主线程的。

基于这两大问题，Redis 提供了增量快照的方式。

RDB 增量快照

增量快照，就是指第一次全量快照后，后续 RDB 快照都是只记录修改过的数据记录，这样就可以避免很多开销。实现的方法就是 第一次全量快照后，数据修改后，会记录下来。这样在下一次增量快照时就知道哪些数据被修改了。

和 AOF 相比，RDB 快照恢复速度快。但是快照的频率设置需要注意了。如果设置的频率很高，宕机可能就会丢失较多数据；频率太低的话，开销也会很大。

AOF 和 RDB 混用

我们在考虑持久化时，肯定希望它恢复速度快，同时开销尽量小，而且尽量丢失少一点的数据。因此，在 Redis4.0 之后，支持了 AOF 和 RDB 混用的方式。

这种方式就是 RDB 以设定的频率执行，比如每 30 秒执行一次。然后没有执行快照的时间内，就用 AOF 日志去记录这段时间内的操作命令。这样一来，就解决了上述对持久化的期望。

小结

对于 RDB 快照和 AOF 文件，我们可根据实际需要去选择。提供一下选择参考：

• 数据可靠性要求高，少丢失： 选择 RDB 快照和 AOF 混用；

• 允许分钟级别的数据丢失： 可以只使用 RDB；

• 只用 AOF：优先考虑 everysec 的配置（可靠性和性能之间的平衡）