redis数据持久化之RDB

最新推荐文章于 2025-04-08 17:01:57 发布

小码农0912

最新推荐文章于 2025-04-08 17:01:57 发布

阅读量744

点赞数 7

分类专栏： redis 文章标签： redis 数据库 redis数据持久化之RDB

本文链接：https://blog.csdn.net/SO_zxn/article/details/145573330

版权

redis 专栏收录该内容

29 篇文章

订阅专栏

文章目录

RDB文件的创建与载入
RDB 文件结构
总结

我们都知道Redis是内存数据库，它将自己的数据库状态储存在内存里面，所以如果不想办法将储存在内存中的数据库状态保存到磁盘，那么如何才能保障redis的数据安全呢？redis自身默认打开RDB持久化，通过RDB将内存中的数据持久化到磁盘保障内存的数据不丢失。

RDB持久化既可以手动执行，也可以根据服务器配置选项定期执行，该功能可以将某个时间点上的数据库状态保存到一个RDB文件中，如图所示：
在这里插入图片描述

RDB持久化功能所生成的RDB文件是一个经过压缩的二进制文件，通过该文件可以还原生成RDB文件时的数据库状态，如图所示：

在这里插入图片描述

因为RDB文件是保存在硬盘里面的，所以即便Redis服务器进程退出，甚至运行Redis服务器的计算机停机，但只要RDB文件仍然存在，Redis服务器就可以用它来还原数据库状态。

本篇会介绍RDB相关的一些实现原理，以及RDB的不足，为后面AOF做铺垫。

RDB文件的创建与载入

RDB创建

有两个Redis命令可以用于生成RDB文件，一个是SAVE，另一个是BGSAVE。

SAVE命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在服务器进程阻塞期间，服务器不能处理任何命令请求。

和SAVE命令直接阻塞服务器进程的做法不同，BGSAVE命令会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求。正常情况下使用的都是BDSAVE命令，这是为了不让客户端阻塞。

RDB载入

和使用SAVE命令或者BGSAVE命令创建RDB文件不同，RDB文件的载人工作是在服务器启动时自动执行的，所以Redis并没有专门用于载入RDB文件的命令，只要Redis服务器在启动时检测到RDB文件存在，它就会自动载入RDB文件。

另外值得一提的是，因为AOF文件的更新频率通常比RDB文件的更新频率高，所以：

如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库状态。
只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态。

当然更高版本的redis还会使用RDB与AOF同事载入的方式。就是在创建RDB文件的间隙使用AOF保存间隔件的命令，在加载时先加载RDB文件，然后加载AOF文件，从而保障加载又快又全。

SAVE命令执行时的服务器状态

前面提到过，当SAVE命令执行时，Redis服务器会被阻塞，所以当SAVE命令正在执行时，客户端发送的所有命令请求都会被拒绝。

只有在服务器执行完SAVE命令、重新开始接受命令请求之后，客户端发送的命令才会被处理。

BGSAVE命令执行时的服务器状态

因为BGSAVE命令的保存工作是由子进程执行的，所以在子进程创建RDB文件的过程中，Redis服务器仍然可以继续处理客户端的命令请求，但是，在BGSAVE命令执行期间，服务器处理SAVE、BGSAVE、BGREWRITEAOF三个命令的方式会和平时有所不同。

首先，在BGSAVE命令执行期间，客户端发送的SAVE命令会被服务器拒绝，服务器禁止SAVE命令和BGSAVE命令同时执行是为了避免父进程（服务器进程）和子进程同时执行两个rdbSave调用，防止产生竞争条件。

其次，在BGSAVE命令执行期间，客户端发送的BGSAVE命令会被服务器拒绝，因为同时执行两个BGSAVE命令也会产生竞争条件。

最后，BGREWRITEAOF和BGSAVE两个命令不能同时执行：

如果BGSAVE命令正在执行，那么客户端发送的BGREWRITEAOF命令会被延退到BGSAVE命令执行完毕之后执行。
如果BGREWRITEAOF命令正在执行，那么客户端发送的BGSAVE命令会被服务器拒绝。

因为BGREWRITEAOF和BGSAVE两个命令的实际工作都由子进程执行，所以这两个命令在操作方面并没有什么冲突的地方，不能同时执行它们只是一个性能方面的考虑一一并发出两个子进程，并且这两个子进程都同时执行大量的磁盘写人操作，这怎么想都不会是一个好主意。

RDB文件载入时的服务器状态

服务器在载入RDB文件期间，会一直处于阻塞状态，直到载入工作完成为止。

自动间隔性保存

因为BGSAVE命令可以在不阻塞服务器进程的情况下执行，所以Redis允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令。

用户可以通过save选项设置多个保存条件，但只要其中任意一个条件被满足，服务器就会执行BGSAVE命令。

设置保存条件

服务器程序会根据save选项所设置的保存条件，设置服务器状态redisServer结构的saveparams属性：
``
struct redisServer{

//记录了保存条件的数组
struct saveparam *saveparams ;

//修改计数器
long long dirty;

//上一次执行保存的时间
time_t lastsave;

} ;
``
dirty计数器记录距离上一次成功执行SAVE命令或者BGSAVE命令之后，服务器对数据库状态（服务器中的所有数据库）进行了多少次修改（包括写入、删除、更新等操作）。

lastsave属性是一个UNIX时间截，记录了服务器上一次成功执行SAVE命令或者BGSAVE命令的时间

saveparams属性是一个数组，数组中的每个元素都是一个saveparam结构，每个saveparamg结构都保存了一个save选项设置的保存条件：

``
struct saveparam{

// 秒数
time_t seconds ;
// 修改数
int changes ;

}
``

检查保存条件是否满足

Redis的服务器周期性操作函数servercron默认每隔100毫秒就会执行一次，该函数用于对正在运行的服务器进行维护，它的其中一项工作就是检查save选项所设置的保存条件是否已经满足，如果满足的话，就执行BGSAVE命令。

RDB 文件结构

我们一起来了解下RDB文件的结构：
在这里插入图片描述

RDB文件的最开头是REDIS部分，这个部分的长度为5字节，保存着RREDIS"五个字符。通过这五个字符，程序可以在载人文件时，快速检查所载入的文件是否RDB文件。类似我们java class文件的 CAFEBABE
db_version长度为4字节，它的值是一个字符串表示的整数，这个整数记录了RDB文件版本号。
databases部分包含着零个或任意多个数据库，以及各个数据库中的键值对数据：
- 如果服务器的数据库状态为空（所有数据库都是空的）那么这个部分也为空，长度
  为0字节。
- 如果服务器的数据库状态为非空（有至少一个数据库非空）那么这个部分也为非空，根据数据库所保存键值对的数量、类型和内容不同，这个部分的长度也会有所不同。
EOF常量的长度为1字节，这个常量标志看RDB文件正文内容的结束，当读人程序退到这个值的时候，它知道所有数据库的所有键值对都已经载人完毕了。
check_sum是一个8字节长的无符号整数，保存着一个校验和，这个校验和是程序通过对 REDIS、db_version、cdatabases、EOF 四个部分的内容进行计算得出的。服务器在载人RDB文件时，会将载入数据所计算出的校验和与check_sum所记录的校验和进行对比，以此来检查RDB文件是否有出错或者损坏的情况出现。