RDB快照

AOF 重写的四个触发时机：

时机一：bgrewriteaof 命令被执行。

时机二：主从复制完成 RDB 文件解析和加载（无论是否成功）。

时机三：AOF 重写被设置为待调度执行。

时机四：AOF 被启用，同时 AOF 文件的大小比例超出阈值，以及 AOF 文件的大小绝对值超出阈值。

另外，这里还需要注意，在这四个时机下，其实都不能有正在执行的 RDB 子进程和 AOF 重写子进程，否则的话， AOF 重写就无法执行了。

AOF 重写的基本执行过程。AOF 重写和 RDB 创建的过程类似，它也是创建了一个子进程来完成重写工作。这是因为 AOF 重写操作，实际上需要遍历 Redis server 上的所有数据库，把每个键值对以插入操作的形式写入日志文

件，而日志文件又要进行写盘操作。所以，Redis 源码使用子进程来实现 AOF 重写，这就避免了阻塞主线程，也减少了对 Redis 整体性能的影响。

RDB快照

RDB 快照就是记录某一个瞬间的内存数据，记录的是实际数据。每次执行快照，都是把内存中的「所有数据」都记录到磁盘中。如果频率太频繁，可能会对 Redis 性能产生影响。如果频率太低，服务器故障时，丢失的数据会更

多。通常可能设置至少 5 分钟才保存一次快照。

Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave，他们的区别就在于是否在「主线程」里执行：

执行了 save 命令，就会在主线程生成 RDB 文件，由于和执行操作命令在同一个线程，所以如果写入 RDB 文件的时间太长，会阻塞主线程；

执行了 bgsave 命令，会创建一个子进程来生成 RDB 文件，这样可以避免主线程的阻塞；

混合持久化

RDB 优点是数据恢复速度快，但是快照的频率不好把握。频率太低，丢失的数据就会比较多，频率太高，就会影响性能。AOF 优点是丢失数据少，但是数据恢复不快。为了集成了两者的优点， Redis 4.0 提出了混合使用 AOF 日

志和内存快照，也叫混合持久化，既保证了 Redis 重启速度，又降低数据丢失风险。