redis文件持久化

最新推荐文章于 2025-06-06 10:17:02 发布

原创最新推荐文章于 2025-06-06 10:17:02 发布 · 376 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#redis #RDB

redis 专栏收录该内容

9 篇文章

订阅专栏

redis文件持久化

本篇文章主要介绍redis的持久化机制，文件的读，写，恢复等内容，希望通过阅读该部分内容，能有一个redis持久化的清晰认识。

附加一个专栏地址，有需要的小伙伴，请移步查看！

redis系列文章

本次内容大纲结构如下：

在这里插入图片描述

1、RDB方式

因为redis还内存数据库，它将自己的数据库状态存在内存里面，如果不想办法保存在磁盘中，那么一旦服务器退出进程，服务器中的状态也会消失不见。RDB持久化方式既可以手动执行，也可以自动执行，该功能可以将某个时间点上的数据库状态保存在一个RDB文件中（经过压缩的二进制文件）。

1.1、文件创建与写入

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

SAVE命令会阻塞Redis服务器进程，直到RDB文件创建爱你完毕为止，在服务器阻塞期间，服务器不能处理任何命令。
BGSAVE命令会派生出一个子进程，然后由子进程负责创建爱你RDB文件，服务器（父进程）继续处理请求命令。

RDB文件的载入工作是在服务器启动时自动执行的，所以Redis并没有专门用于载入RDB文件的命令，只要Redis服务器在启动时检测到RDB文件存在，就会自动载入RDB文件。另外，因为AOF文件的更新频率比RDB文件高，所以如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库。

BGSAVE、SAVE和BGREWRITEAOF命令不能同时执行；服务器在载入文件期间，会一直处于阻塞状态，直到载入工作完成为止。

1.2、自动间隔性保存

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

例如（默认条件）：
save 900 1
save 300 10
save 60 10000

含义如下：

服务器在900秒内，对数据库进行了至少1此修改。
服务器在300秒内，对数据库进行了至少10此修改。
服务器在60秒内，对数据库进行了至少10000此修改。

除了保存条件，服务器状态还维持着一个dirty计数器，以及一个lastsave属性：

dirty计数器记录距离上一次成功执行save或者bgsave命令之后，服务器对数据库状态进行了多少次修改（包括写入，删除和更新）。
lastsave：属性是一个UNIX时间戳，记录了服务器上一次成功执行save或者bgsave命令的时间。

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

在这里插入图片描述

1.3、文件结构

RDB文件的结构如下：

在这里插入图片描述

REDIS部分是文件的开头，长度为5个字节，保存“redis”字符，用于快速检查是否是RDB文件。
db_version长度为4个字节，它的值是一个字符串表示的整数，记录了RDB文件的版本号。
databases部分包含着零个或者任意多个数据库，以及各个数据库中的键值对数据。如果服务器的数据库状态为空，那么这个部分也为空，长度为0；如果非空，根据数据库保存键值对的数量、类型和内容不同，长度也不同。
EOF常量的长度为1字节，标志RDB文件的结束。
check_sum是一个8字节的无符号整数，保存着一个校验和，检查RDB文件是否出错或者损坏。
SELECTDB常量的长度为1字节，表示接下来是数据库号码。
db_number保存着一个数据库号码，可以是1,2或者5字节。
key_value_pairs部分保存着数据库中的所欲键值对，如果设置了过期时间，过期时间也会保存。根据键值对的数量，类型，内容以及是否有过期时间等条件的不同，长度也会不同。