九. Redis 持久化-RDB(详细讲解说明，一个配置一个说明分析，步步讲解到位)

九. Redis 持久化-RDB(详细讲解说明，一个配置一个说明分析，步步讲解到位)

@
目录

• [九. Redis 持久化-RDB(详细讲解说明，一个配置一个说明分析，步步讲解到位)](#九. Redis 持久化-RDB(详细讲解说明，一个配置一个说明分析，步步讲解到位))
• [1. RDB 概述](#1. RDB 概述)
• [2. RDB 持久化执行流程](#2. RDB 持久化执行流程)
• [3. RDB 的详细配置](#3. RDB 的详细配置)
• [4. RDB 备份&恢复](#4. RDB 备份&恢复)
• [5. RDB 持久化小结(优势 和 劣势)](#5. RDB 持久化小结(优势 和 劣势))
• [6. 最后：](#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 及其执行流程：

对上图的解读：

具体流程如下：

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 的配置。

如何配置

默认为 Redis 启动时命令行所在的目录下：

意思就是：默认会将 "dump.rdb" 快照文件存储到 Redis 启动时命令行所在的目录下

重点： 进入到/usr/local/bin 目录下, 启动 Redis, 这个那么这里的 ./ 所指的路径就是 /usr/local/bin , 如果你在 /root/ 目录下启动 Redis , 那么这里 ./ 所指的就是 /root/ 下了路径 , 这点请大家注意。

那么这样的默认配置就存在一个问题，那就是，如果我们每次去到不同的目录下启动 redis 的化，那么这个dump.rdb（快照存储我们信息/数据的文件） 就会存储到不同的目录下，这样就导致了，如果该目录下没有我们之前执行存储的数据的 dump.rdb 文件的话，我们Redis 就无法读取到该存有我们之前dump.rdb 数据的文件，也就无法恢复我们之前存储操作的数据了。

演示：

我们创建两个目录：分别是: test01，和 test02
在 test01 目录下执行 set k1 "test01"  同时查看该目录下是否生成 dump.rdb(快照文件)
在 test02 目录下执行 set k2 "test02" 同时查看该目录下是否生成 dump.rdb(快照文件)

[root@localhost home]# mkdir test01 # 创建目录

[root@localhost test01]# redis-cli
127.0.0.1:6379> keys *
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth rainbowsea
OK
127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379> set k1 "test01"
OK
127.0.0.1:6379> keys *
1) "k1"

同理执行：test02

怎么解决这个，Redis 在不同的目录下，导致数据存储快照不同，数据没有跟上？

我们可以自定义配置好这个 dump.rdb 文件的存放路径，不是默认的dir./(根据启动Redis目录不同而变化) ，而是一直配置在一个固定的路径下。就可以解决这个问题了。

这里我们将其配置到 /root/ 目录下，这样我们每次生成的 dump.rdb 文件就一直是在同一个路径的目录下了

dir /root/

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

[root@localhost test02]# redis-server /etc/redis.conf
[root@localhost test02]# redis-cli

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 秒钟 写操作次数, 如图

RDB 是整个内存的压缩过的 Snapshot，RDB 的数据结构，可以配置复合的快照触发条件 。

禁用：给 save 传空字符串，可以看文档：

5. stop-writes-on-bgsave-error
   

意思是：当 Redis 无法写入磁盘的话(比如磁盘满了), 直接关掉 Redis 的写操作。推荐 yes

6. rdbcompression

该配置的意思是：

1. 对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis 会采用 LZF 算法进行压缩。
2. 如果你不想消耗 CPU 来进行压缩的话，可以设置为关闭此功能，默认 yes。

7. rdbchecksum

该配置的意思是：

1. 在存储快照后，还可以让 redis 使用 CRC64算法来进行数据校验，保证文件是完整的。
2. 但是这样做会增加大约 10% 的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能，推荐 yes 打开。

8. 动态停止 RDB：

9. 动态停止RDB： redis-cli config set save "" ，就是给 save 属性赋值为 ""空字符串，表示禁用保护策略。这里使用命令是让 客户端在此刻，启动的客户端停止 RDB，一旦退出了该客户端就，该配置就失效了。RDB 持久化策略又启动了。

---

示例演示：

需求: 如果 Redis 的 key 在 30 秒内, 有 5 个 key 变化, 就自动进行 RDB 备份.

save 30 5

4. RDB 备份&恢复

Redis 可以充当缓存，对项目进行优化，因此重要/敏感的数据建议在 MySQL要保存一份。

从设计层面来说，Redis 的内存数据，都是可以重新获取的(可能来自程序，也可能来自MySQL)

因此我们这里说的备份&恢复 ：主要是给大家说明一下 Redis 启动时，初始化数据是从 dump.rdb 来的 整个机制。

演示：

这里我们演示的是：

将我们已经的 dump.rdb 备份文件复制拷贝(备份)一份，复制后之后，再将原来的dump.rdb 文件删除了(模拟文件损坏了，或者是执行 flushall 删除库)。再将我们拷贝备份的 dum.rdb 文件，复制过去，然后重启 redis 读取 dump.rdb 备份文件当中的数据，进行一个数据上的恢复。

config get dir 查询 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

127.0.0.1:6379> flushall

注意：这里得关闭一下服务器

[root@localhost ~]# rm /root/dump.rdb # 删除文件夹

关闭 Redis 服务器，重新启动 Redis 服务器，让它读取到我们配置的dump.rdb 备份文件，恢复我们的数据信息。

5. RDB 持久化小结(优势 和 劣势)

优势：

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

劣势：

1. 虽然 Redis 在 fork 时使用了写时拷贝技术(Cop-On-Write) ，但是如果数据庞大时还是比较消耗性能。
2. 在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉 的话(如果正常关闭 Redis仍然会进行 RDB 备份，不会丢失数据)，就会丢失最后一次快照后的所有修改。

6. 最后：

"在这个最后的篇章中，我要表达我对每一位读者的感激之情。你们的关注和回复是我创作的动力源泉，我从你们身上吸取了无尽的灵感与勇气。我会将你们的鼓励留在心底，继续在其他的领域奋斗。感谢你们，我们总会在某个时刻再次相遇。"