Redis持久化--RDB

一. RDB是什么

在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就 Snapshot 快照，恢复时将快照文件读到内存

二. RDB持久化的流程

解读：

1. redis 客户端执行 bgsave 命令或者自动触发 bgsave 命令；
2. 主进程判断当前是否已经存在正在执行的子进程，如果存在，那么主进程直接返回；
3. 如果不存在正在执行的子进程，那么就 fork 一个新的子进程进行持久化数据，fork 过程是阻塞的，fork 操作完成后主进程即可执行其他操作；
4. 子进程先将数据写入到临时的 rdb 文件中，待快照数据写入完成后再原子替换旧的 rdb文件；
5. 同时发送信号给主进程，通知主进程 rdb 持久化完成，主进程更新相关的统计信息

总结：

1. 整个过程中，主进程是不进行任何 IO 操作的，这就确保了极高的性能
2. 如果需要进行大规模数据的恢复, 且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效
3. 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.注意事项

1. 当我们在一个新目录启动redis后，通过keys * 命令会看不到原来的数据，试试
2. 此时我们在/usr/local/bin目录下启动redis,此时会在该目录下生成一个dump.rdb文件，当我们在执行shutdown 命令时，会将内存中的数据持久化到该文件
   
3. 此时我们在一个新的目录启动redis
   
   

四. 相关配置&参数&操作

1. 默认快照配置

2. save&bgsave

1. Save 手动保存，save 时只管保存，其它不管，全部阻塞。手动保存, 不建议
   
2. bgsave
   Redis 会在后台异步进行快照操作， 快照同时还可以响应客户端请求
   
3. lastsave: 可以通过 lastsave 命令获取最后一次成功执行快照的时间(unix 时间戳) , 可以使用工具转换
4. flushall 执行 flushall 命令，也会产生 dump.rdb 文件, 数据为空 Redis Flushall 命令用于清空整个 Redis 服务器的数据(删除所有数据库的所有 key,内存中以及dump.rdb文件中全部清除）
5. Save RDB 是整个内存的压缩过的 Snapshot，RDB 的数据结构，可以配置复合的快照触发条件， 禁用: 给 save 传入空字符串, 可以看文档
6. stop-writes-on-bgsave-error
   
   当 Redis 无法写入磁盘的话(比如磁盘满了), 直接关掉 Redis 的写操作。推荐 yes
7. Rdbchecksum 在存储快照后, 还可以让 redis 使用 CRC64 算法来进行数据校验，保证文件是完整的。 但是这样做会增加大约 10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能, 推荐 yes
8. 动态停止 RDB（即不想改配置文件，临时修改该配置）：
   redis-cli config set save “”
   说明: save 后给空值，表示禁用保存

五. 总结

优势
• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高更适合使用
• 节省磁盘空间（本身支持压缩算法）
• 恢复速度快（存的就是数据，恢复非常快）
劣势： 虽然 Redis 在 fork 时使用了写时拷贝技术(Copy-On-Write), 但是如果数据庞大时还是比较消耗性能。 在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉的话(如果正常关闭 Redis, 仍然会进行 RDB 备份, 不会丢失数据), 就会丢失最后一次快照后的所有修改