一. RDB是什么
在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就 Snapshot 快照，恢复时将快照文件读到内存
二. RDB持久化的流程
解读：
- redis 客户端执行 bgsave 命令或者自动触发 bgsave 命令；
- 主进程判断当前是否已经存在正在执行的子进程，如果存在，那么主进程直接返回；
- 如果不存在正在执行的子进程，那么就 fork 一个新的子进程进行持久化数据，fork 过程是阻塞的，fork 操作完成后主进程即可执行其他操作；
- 子进程先将数据写入到临时的 rdb 文件中，待快照数据写入完成后再原子替换旧的 rdb文件；
- 同时发送信号给主进程，通知主进程 rdb 持久化完成，主进程更新相关的统计信息
总结：
- 整个过程中，主进程是不进行任何 IO 操作的，这就确保了极高的性能
- 如果需要进行大规模数据的恢复, 且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效
- RDB 的缺点是最后一次持久化后的数据可能丢失 老韩解读 -如果你是正常关闭 Redis（即执行shutdown） , 仍然会进行持久化, 不会造成数据丢失 -如果是 Redis 异常终止/宕机, 就可能造成数据丢失 -后面在讲解快照配置 , 还会举例说明
三. RDB的配置
1. dump.rdb文件
在 redis.conf 中配置文件名称, 默认为 dump.rdb
2. 如何配置
○ 该文件生成的位置默认为 Redis 启动时命令行所在的目录下
○ 进入到/usr/local/bin 目录下, 启动 Redis, 这个 ./ 就是 /usr/local/bin , 如果你在/root/ 目录下启动 Redis , 那么 ./ 就是 /root/ 下了 , 这点请注意
○ rdb 文件的保存路径, 也可以修改, 比如: dir “/root/” , 演示一下
3.注意事项
- 当我们在一个新目录启动redis后，通过keys * 命令会看不到原来的数据，试试
- 此时我们在/usr/local/bin目录下启动redis,此时会在该目录下生成一个dump.rdb文件，当我们在执行shutdown 命令时，会将内存中的数据持久化到该文件
- 此时我们在一个新的目录启动redis
四. 相关配置&参数&操作
1. 默认快照配置
2. save&bgsave
- Save 手动保存，save 时只管保存，其它不管，全部阻塞。手动保存, 不建议
- bgsave
Redis 会在后台异步进行快照操作， 快照同时还可以响应客户端请求
- lastsave: 可以通过 lastsave 命令获取最后一次成功执行快照的时间(unix 时间戳) , 可以使用工具转换
- flushall 执行 flushall 命令，也会产生 dump.rdb 文件, 数据为空 Redis Flushall 命令用于清空整个 Redis 服务器的数据(删除所有数据库的所有 key,内存中以及dump.rdb文件中全部清除）
- Save RDB 是整个内存的压缩过的 Snapshot，RDB 的数据结构，可以配置复合的快照触发条件， 禁用: 给 save 传入空字符串, 可以看文档
- stop-writes-on-bgsave-error
当 Redis 无法写入磁盘的话(比如磁盘满了), 直接关掉 Redis 的写操作。推荐 yes - Rdbchecksum 在存储快照后, 还可以让 redis 使用 CRC64 算法来进行数据校验，保证文件是完整的。 但是这样做会增加大约 10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能, 推荐 yes
- 动态停止 RDB（即不想改配置文件，临时修改该配置）：
redis-cli config set save “”
说明: save 后给空值，表示禁用保存
五. 总结
优势
• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高更适合使用
• 节省磁盘空间（本身支持压缩算法）
• 恢复速度快（存的就是数据，恢复非常快）
劣势： 虽然 Redis 在 fork 时使用了写时拷贝技术(Copy-On-Write), 但是如果数据庞大时还是比较消耗性能。 在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉的话(如果正常关闭 Redis, 仍然会进行 RDB 备份, 不会丢失数据), 就会丢失最后一次快照后的所有修改
