Redis的RDB快照

AOF（Append On File）方法，每次执行只需要记录操作命令，每次需要持久化的数据量不大。只要采用的不是always的持久化策略，就不会对性能造成太大影响。也正因为记录的是操作命令，而不是实际的数据，所以，用AOF方法进行故障恢复时，需要逐一把命令都执行一遍。如果操作日志非常多，Redis就会恢复得很缓慢，影响正常使用。而RDB（Redis DataBase）日志文件记录的是内存快照，就是指内存中的数据在某一时刻的状态记录。

RDB文件是什么？

Redis的数据都在内存中，为了提供所有数据的可靠性，它执行的是全量快照，也就是把内存中的所有数据都记录到磁盘中。

RDB文件的生成？

Redis提供了两个命令来生成RDB文件：

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

RDB文件的生成流程？

Redis借助操作系统提供的写时复制（copy on write），在执行快照的同时，正常处理读写操作。这里的操作和操作AOF文件重写是一样的，但是AOF文件写完之后会提示主线程，并对在重写期间的写操作进行追加。而RDB文件不做追加。详情可以点击以下连接Redis的AOF日志。

RDB文件的细节？

1. 虽然bgsave执行不阻塞主线程，但如果频繁地执行全量快照，会带来两方面的开销。1、磁盘压力变大 2、主进程fork子进程这个创建过程本身会阻塞主进程，而且内存中数据量越大，阻塞时间越大。
2. Redis4.0中提出混合使用AOF日志和内存快照的方法。设置的参数：aof-use-rdb-preamble：yes。

RDB文件与AOF文件的优缺点？

• AOF:恢复数据时间与记录的命令成正比相关。相比于RDB文件的恢复，AOF恢复时是一条命令一条命令地执行。
• RDB:快照对磁盘和内存开销大，不能频繁记录。相比于RDB文件的一次fork子进程写文件相比，AOF对文件的写操作分散在每次命令执行完后。而AOF日志的重写也不会很频繁。

RDB和AOF的选择问题？

• 数据不能丢失时，内存快照和AOF的混合使用是个很好的选择。
• 如果允许分钟级别的数据丢失，可以只使用RDB。
• 如果只能AOF，优先使用everysec的配置选项，因为它在可靠性和性能之间取了一个平衡。

混合使用AOF日志和内存快照？

在Redis4.0以前，RedisAOF的重写机制是指令整合，也就是这里的重写Redis的AOF日志。但在Redis4.0之后，Redis的AOF重写的时候就直接把RDB的内容写到AOF文件开头，将增量的以指令的方式Append到AOF文件。

• 优点：快速加载，同时避免丢失过多数据。
• 缺点：AOF里面的RDB部分就是压缩格式不再是AOF格式，可读性差。

Redis4.0之后在读取AOF文件怎么判断RDB数据？

查看是否以REDIS开头。