RDB 快照是怎么实现的？
AOF 文件的内容是操作命令；
- 每次更新添加一条命令，生成快，但是恢复慢
RDB 文件的内容是二进制数据。
- 恢复更快，但是创建全量，所以很慢
快照怎么用？
Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave：
- 执行了 save 命令，就会在主线程生成 RDB 文件，由于和执行操作命令在同一个线程，所以如果写入 RDB 文件的时间太长，会阻塞主线程；
- 执行了 bgsave 命令，会创建一个子进程来生成 RDB 文件，这样可以避免主线程的阻塞；（默认使用）
RDB 文件的加载工作是在服务器启动时自动执行的，Redis 并没有提供专门用于加载 RDB 文件的命令。
Redis 还可以通过配置文件的选项来实现每隔一段时间自动执行一次 bgsave 命令。
Redis 的快照是全量快照，也就是说每次执行快照，都是把内存中的「所有数据」都记录到磁盘中。
执行快照时，数据能被修改吗？
执行 bgsave 过程中，Redis 依然可以继续处理操作命令的，也就是数据是能被修改的。
关键的技术就在于写时复制技术（Copy-On-Write, COW）。
Redis 使用 bgsave 对当前内存中的所有数据做快照，这个操作是由 bgsave 子进程在后台完成的，执行时不会阻塞主线程，这就使得主线程同时可以修改数据。
所以 Redis 在使用 bgsave 快照过程中，如果主线程修改了内存数据，不管是否是共享的内存数据，RDB 快照都无法写入主线程刚修改的数据，因为此时主线程（父进程）的内存数据和子进程的内存数据已经分离了，子进程写入到 RDB 文件的内存数据只能是原本的内存数据。
如果系统恰好在 RDB 快照文件创建完毕后崩溃了，那么 Redis 将会丢失主线程在快照期间修改的数据。
另外，写时复制的时候会出现这么个极端的情况。
在 Redis 执行 RDB 持久化期间，刚 fork 时，主进程和子进程共享同一物理内存，但是途中主进程处理了写操作，修改了共享内存，于是当前被修改的数据的物理内存就会被复制一份。
那么极端情况下，如果所有的共享内存都被修改，则此时的内存占用是原先的 2 倍。
所以，针对写操作多的场景，我们要留意下快照过程中内存的变化，防止内存被占满了。
RDB 和 AOF 合体
尽管 RDB 比 AOF 的数据恢复速度快，但是快照的频率不好把握：
- 如果频率太低，两次快照间一旦服务器发生宕机，就可能会丢失比较多的数据；
- 如果频率太高，频繁写入磁盘和创建子进程会带来额外的性能开销。
Redis 4.0 提出的混合使用 AOF 日志和内存快照，也叫混合持久化。
混合持久化工作在 AOF 日志重写过程。
当开启了混合持久化时，在 AOF 重写日志时，fork 出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件，然后主线程处理的操作命令会被记录在重写缓冲区里，重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件，写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。
也就是说，使用了混合持久化，AOF 文件的前半部分是 RDB 格式的全量数据，后半部分是 AOF 格式的增量数据。
这样的好处在于，重启 Redis 加载数据的时候，由于前半部分是 RDB 内容，这样加载的时候速度会很快。
加载完 RDB 的内容后，才会加载后半部分的 AOF 内容，这里的内容是 Redis 后台子进程重写 AOF 期间，主线程处理的操作命令，可以使得数据更少的丢失。
并没有显式的边界标识来直接区分RDB和AOF的边界。但是，由于RDB和AOF的格式和内容本质上是不同的（RDB是二进制格式，AOF是文本格式），因此在解析混合持久化文件时，Redis能够根据文件格式和内容的不同来自动区分RDB和AOF部分。