Redis持久化之RDB深入剖析（配置与解析分步阐释）

九. Redis 持久化 - RDB(深度剖析阐述，配置与解析分步解读)

目录

• 九. Redis 持久化 - RDB(深度剖析阐述，配置与解析分步解读)
• 1. RDB 基本概述
• 2. RDB 持久化运作流程
• 3. RDB 的详细配置情况
• 4. RDB 备份与恢复操作
• 5. RDB 持久化总结(优点和缺点)
• 6. 结尾：

Redis 持久化 - RDB：官网文档地址：
https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/

Redis 的持久化方案有两种：
1. RDB(Redis DataBase)
2. AOF(Append Of File)

这里我们重点讲解 RDB 持久化方案，AOF 持久化方案会在后续文章中介绍。

1. RDB 基本概述

RDB 是什么？
在设定的时间间隔内，把内存里的数据集以快照（Snapshot）的形式写入到磁盘中，恢复的时候再把快照文件里的内容读取到内存里。

2. RDB 持久化运作流程

RDB 及其执行流程：
Redis持久化之RDB深入剖析（配置与解析分步阐释）

对上图的解读：

具体流程如下：

1. Redis 客户端执行 bgsave 命令或者自动触发 bgsave 命令。
2. 主进程检查当前是否有正在运行的子进程，如果有，主进程直接返回。
3. 如果没有正在运行的子进程，就 fork 出一个新的子进程来进行持久化数据操作，fork 过程会阻塞，fork 完成后主进程可以继续执行其他操作。
4. 子进程先把数据写入到临时的 rdb 文件中，待快照数据写入完成后，再原子性地替换掉旧的 rdb 文件。
5. 同时子进程发送信号给主进程，通知主进程 rdb 持久化完成，主进程更新相关统计信息。

小结：

1. 整个过程中，主进程不进行任何 IO 操作，保证了很高的性能。
2. 如果需要大规模恢复数据，且对数据恢复的完整性要求不是特别高，那么 RDB 方式比 AOF 方式更高效。
3. RDB 的缺点是最后一次持久化后的数据可能会丢失。

正常关闭 Redis 时，仍然会进行持久化，不会丢失数据。但如果 Redis 异常终止/宕机，就可能丢失最后一次持久化后的数据。后面讲解快照配置时会详细说明。

Fork & Copy - On - Write：
1. Fork 的作用是复制出一个和当前进程相同的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但它是一个全新的进程，作为原进程的子进程。
2. 在 Linux 程序中，fork() 会生成一个和父进程完全相同的子进程，但子进程之后通常会执行 exec 系统调用，为了提高效率，Linux 引入了“写时复制技术（copy - on - write）”，感兴趣的可以参考🌟🌟🌟 https://blog.csdn.net/Code_beeps/article/details/92838520 一位网友的解读。
3. 一般情况下父进程和子进程会共用一段物理内存，只有进程空间的各段内容发生变化时，才会把父进程的内容复制一份给子进程。

3. RDB 的详细配置情况

1. 默认快照配置

Redis 中的快照文件名为 dump.rdb，这是默认的。在 /etc/redis.conf 文件中可以找到这个 dump.rdb 的配置。
默认情况下，dump.rdb 快照文件会存储在 Redis 启动时命令行所在的目录下。例如，进入到 /usr/local/bin 目录下启动 Redis，那么 ./ 所指的路径就是 /usr/local/bin；如果在 /root/ 目录下启动 Redis，那么 ./ 所指的就是 /root/ 路径。需要注意这一点。

存在的问题：如果每次在不同目录下启动 Redis，dump.rdb 快照文件会存储在不同目录，导致如果某个目录下没有之前存储数据的 dump.rdb 文件，Redis 就无法恢复之前的数据。

解决方法： 可以自定义 dump.rdb 文件的存放路径，使其固定在一个目录下。比如将其配置到 /root/ 目录下，配置如下：

dir /root/

注意：需要关闭 Redis 服务，重新启动 Redis 服务，配置才会生效。

2. save 和 bgsave

127.0.0.1:6379> save

127.0.0.1:6379> bgsave

默认的快照配置同样在 /etc/redis.conf 文件中配置。

注意理解时间段的概念：
如果没有开启 save 的注释，那么在退出 Redis 时，也会进行备份，更新 dump.rdb 文件。
* save：save 时只负责保存，其他操作都被阻塞，手动保存时不建议使用。
* bgsave：Redis 会在后台异步进行快照操作，快照过程中还可以响应客户端请求。
* 可以通过 lastave 命令获取最后一次成功执行快照的时间（unix 时间戳），可以使用工具转换时间戳，网址为 https://tool.lu/timestamp/。

3. flushall

执行 flushall 命令，也会生成 dump.rdb 文件，此时文件中的数据为空。Redis Flushall 命令用于清空整个 Redis 服务器的数据（删除所有数据库的所有 key）。

4. Save

格式为 save 秒钟 写操作次数，例如：

save 30 5

表示如果在 30 秒内有 5 个 key 发生变化，就自动进行 RDB 备份。RDB 是整个内存的压缩快照，其数据结构可以配置复合的快照触发条件。禁用 save 可以传空字符串，可参考文档。

5. stop - writes - on - bgsave - error

意思是：当 Redis 无法写入磁盘时（比如磁盘满了），直接关闭 Redis 的写操作，推荐设置为 yes。

6. rdbcompression

该配置表示：对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果开启，redis 会采用 LZF 算法进行压缩；如果不想消耗 CPU 进行压缩，可以关闭该功能，默认是 yes。

7. rdbchecksum

该配置表示：在存储快照后，redis 可以使用 CRC64 算法进行数据校验，保证文件完整。但这样会增加大约 10% 的性能消耗，如果希望获得最大性能提升，可以关闭该功能，推荐开启（yes）。

8. 动态停止 RDB

动态停止 RDB 的命令是 redis - cli config set save ""，即给 save 属性赋值为空字符串，表示禁用保护策略。不过该配置在客户端退出后会失效，RDB 持久化策略会重新启用。

4. RDB 备份与恢复操作

Redis 可作为缓存优化项目，重要/敏感数据建议在 MySQL 中也保存一份。从设计层面看，Redis 的内存数据通常可以重新获取（可能来自程序或 MySQL）。这里所说的备份与恢复主要是说明 Redis 启动时初始化数据是从 dump.rdb 来的机制。

演示步骤：
将已有的 dump.rdb 备份文件复制一份，然后删除原来的 dump.rdb 文件（模拟文件损坏或执行 flushall 删除库的情况），再将备份的 dump.rdb 文件复制过去，重启 redis，使其读取备份文件中的数据恢复。

查询 rdb 文件目录的命令：

127.0.0.1:6379> config get dir

将 dump.rdb 进行备份，必要时可以写 shell 脚本定时备份（可参考韩顺平老师 Linux 课程中定时备份 Mysql 数据库的视频地址 https://www.bilibili.com/video/BV1Sv411r7vd?p=105）。

[root@localhost ~]# cp /root/dump.rdb /root/dump.rdb.bak

执行 flushall 命令清空数据：

127.0.0.1:6379> flushall

关闭 Redis 服务器，删除原来的 dump.rdb 文件，然后重新启动 Redis 服务器，使其读取备份的 dump.rdb 文件恢复数据。

5. RDB 持久化总结(优点和缺点)

优点：
1. 适合大规模数据恢复。
2. 对数据完整性和一致性要求不高时更适用。
3. 节省磁盘空间。
4. 恢复速度快。

缺点：
1. 虽然 Redis 在 fork 时使用写时拷贝技术，但数据庞大时仍较消耗性能。
2. 若备份周期有间隔，Redis 意外宕机（正常关闭时会进行 RDB 备份，不会丢失数据），会丢失最后一次快照后的所有修改。

6. 结尾：

“在这篇文章的最后部分，我要向每一位读者表达我的谢意。你们的关注与回应是我持续创作的动力，从你们身上我汲取了无数灵感与勇气。我会将这份鼓励铭记于心，继续在相关领域努力前行。期待与你们在未来的某个时刻再次相遇。”