1. RDB介绍
RDB（Redis DataBase），其工作原理就是在指定的时间间隔，执行数据集的时间点快照，实现类似照片记录效果的方式。
换句话说，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。这个快照文件就称为RDB文件(dump.rdb)。
2. 优缺点
2.1 优点
- RDB是Redis 数据的一个非常紧凑的单文件时间点表示。RDB文件非常适合备份。例如，您可能希望在最近的24小时内每小时归档一次RDB文件，并在30天内每天保存一个RDB快照。这使您可以在发生灾难时轻松恢复不同版本的数据集。
- RDB非常适合灾难恢复，它是一个可以传输到远程数据中心或Amazon S3(可能已加密）的压缩文件。
- RDB最大限度地提高了Redis 的性能，因为Redis 父进程为了持久化而需要做的唯一工作就是fork一个子进程，接下来的持久化工作全部由子进程完成。父进程永远不会执行磁盘I/О或类似操作。
- 与AOF 相比，RDB允许使用大数据集更快地重启。
- 在副本上，RDB支持重启和故障转移后的部分重新同步。
2.2 缺点
-
如果您需要在Redis停止工作时（例如断电后）将数据丢失的可能性降到最低，那么RDB并不好。您可以配置生成RDB的不同保存点（例如，在对数据集至少5分钟和100次写入之后，您可以有多个保存点)。但是，您通常会每五分钟或更长时间创建一次RDB快照，因此，如果Redis由于任何原因在没有正确关闭的情况下停止工作，您应该准备好丢失最新分钟的数据。
-
RDB需要经常
fork()以便使用子进程在磁盘上持久化。如果数据集很大，fork()可能会很耗时，并且如果数据集很大并且CPU性能不是很好，可能会导致Redis停止为客户端服务几毫秒甚至一秒钟。注：
fork（）函数个人理解就是将主进程复制，创建一个与主进程完全相同的子进程
2.3 总结
RDB个人理解就是每隔一定的时间就将目前Redis中的数据写到磁盘上，这样，即使Redis宕机，在重连后也可以继续加载数据。
这样的不足也很容易能想到：
- 无法保证将所有的数据都进行备份。假如每分钟备份一次，那么如果在半分钟的时候宕机，这时，磁盘数据中就只有上个分钟的数据，最近的这半分钟数据还没有来得及备份。
- RDB在进行持久化时，需要调用fork()。虽然fork同步速度比较快，但是当数据量比较大的时候，也会对Redis的性能产生影响。
3. RDB详解
3.1 哪些情况会触发RDB快照
- 配置文件中默认的快照配置
- 手动
save/bgsave命令 - 执行
flushdb/fulshall命令也会产生dump.rdb文件，但是也会将命令记录到dump.rdb文件中，恢复后依旧是空，无意义 - 执行
shutdown且没有设置开启AOF持久化 - 主从复制时，主节点自动触发
3.2 RDB配置项
-
save \<seconds> \<changes>：配置快照保存条件 -
dir：配置快照保存目录地址 -
dbfilename：配置快照的文件名 -
top-writes-on-bgsave-error： 默认yes，如果配置成no，表示不在乎数据不一致或者有其他的手段发现和控制这种不一致，那么在快照写入失败时，也能确保redis继续接受新的请求 -
rdbcompression：默认yes，对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，Redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能 -
rdbchecksum：默认yes，在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能 -
rdb-del-sync-files：在没有持久化的情况下删除复制中使用的RDB文件。默认情况下no，此选项是禁用的。