前言
我们都知道，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 的配置（可靠性和性能之间的平衡）
