Redis 中的数据持久化策略（RDB）

最新推荐文章于 2024-09-21 18:28:39 发布
最新推荐文章于 2024-09-21 18:28:39 发布
阅读量2.6k 收藏 3
点赞数 1
分类专栏： DB/数据库 Cache缓存 文章标签： redis 数据库 快照持久化策略 RDB
原文链接：https://www.cnblogs.com/yangming1996/p/12152090.html
版权
Redis的RDB持久化策略通过内存快照保存数据，包括同步和异步方式。默认配置如save9001等决定何时触发bgsave。rdb文件包含MagicNumber、REDIS_VERSION、AuxFields等字段，键值对存储采用特定格式。当满足配置条件时，serverCron会触发RDB文件生成。
摘要由CSDN通过智能技术生成

Redis 是一个内存数据库，所有的数据都直接保存在内存中，那么，一旦 Redis 进程异常退出，或服务器本身异常宕机，我们存储在 Redis 中的数据就凭空消失，再也找不到了。

Redis 作为一个优秀的数据中间件，必定是拥有自己的持久化数据备份机制的，redis 中主要有两种持久化策略，用于将存储在内存中的数据备份到磁盘上，并且在服务器重启时进行备份文件重载。

RDB 和 AOF 是 Redis 内部的两种数据持久化策略，这是两种不同的持久化策略，一种是基于内存快照，一种是基于操作日志，那么本篇就先来讲讲 RDB 这种基于内存快照的持久化策略。

一、什么是 RDB 持久化策略

RDB（redis database），快照持久化策略。RDB 是 redis 默认的持久化策略，你可以打开 redis.conf，默认会看到这三条配置。
redis-rdb配置

save 900 1           # 900秒内执行一次set操作 则持久化1次  
save 300 10         # 300秒内执行10次set操作,则持久化1次
save 60 10000     # 60秒内执行10000次set操作,则持久化1次

RDB 又分为两种：

  • 一种是同步的，调用 save 命令即可触发 redis 进行 RDB 文件生成备份，但是这是一个同步命令，在备份完成之前，redis 服务器不响应客户端任何请求。
  • 另一种是异步的，调用 bgsave 命令，redis 服务器 fork 一个子进程进行 RDB 文件备份生成，与此同时，主进程依然可以响应客户端请求。

显然，异步的 RDB 生成策略才是主流，除了某些特殊情况，相信不会有人会在生产环境中用 save 命令阻塞 redis 服务来生成 RDB 文件的。

以上我们介绍的两个命令，save 和 bgsave 这两个命令需要我们手动的在客户端发送请求才能触发，我们叫做 主动触发。

而我们之前匆匆介绍过的配置触发，这种我们叫做 被动触发，被动触发有一些配置，下面我们来看看。

1、save 配置

save 配置是一个非常重要的配置，它配置了 redis 服务器在什么情况下自动触发 bgsave 异步 RDB 备份文件生成。

基本语法格式：

save <seconds> <changes>

当 redis 数据库在多少秒内，数据库中的 keys 发生了多少次变化，那么就会触发 bgsave 命令的调用。

2、dbfilename 配置

dbfilename 配置项决定了生成的 RDB 文件名称，默认配置为 dump.rdb。

dbfilename dump.rdb

3、rdbcompression 配置

rdbcompression 配置的是 rdb 文件中压缩启用配置，基本语法格式：

rdbcompression yes(|no)

如果 rdbcompression 配置为 yes，那么即代表 redis 进行 RDB 文件生成中，如果遇到字符串对象并且其中的字符串值占用超过 20 个字节，那么就会对字符串进行 LZF 算法进行压缩。

4、stop-writes-on-bgsave-error 配置

stop-writes-on-bgsave-error 配置了，如果进行 RDB 备份文件生成过程中，遭遇错误，是否停止 redis 提供写服务，以警示用户 RDB 备份异常，默认是开启状态。

stop-writes-on-bgsave-error yes(|no)

5、dir 配置

dir 配置的是 rdb 文件存放的目录，默认是当前目录。

dir ./

6、rdbchecksum 配置

rdbchecksum 配置 redis 是否使用 CRC64 校验算法校验 RDB 文件是否发生损坏，默认开启状态，如果你需要提升性能，可以选择性关闭。

rdbchecksum yes(|no)

二、saveparams 和 dirty 计数器

我们 redisServer 结构体中有这么两个字段：
redis server 结构体字段
saveparams 结构定义如下：

struct saveparam {
    time_t seconds;  //秒数
    int changes;    //变更次数
};

相信你能够想到，上述配置文件中的 save 配置就对应了两个参数，多少秒内数据库发生了多少次的变更便触发 bgsave。

映射到代码就是我们 saveparam 结构，每一个 saveparam 结构都对应一行 save 配置，而最终会以 saveparam 数组的形式被读取到 redisServer 中。

ps：介绍这个目的是为我们稍后分析 RDB 文件生成的源码实现做前置铺垫。

除此之外，redisServer 数据结构中还有这么两个字段：
在这里插入图片描述

  • dirty 字段记录了自上次成功备份 RDB 文件之后，包括 save 和 bgsave 命令，整个 redis 数据库又发生了多少次修改。
  • dirty_before_bgsave 字段可以理解为上一次 bgsave 命令备份时，数据库总的修改次数。

还有一些跟持久化相关时间字段，上一次成功 RDB 备份的时间点，上一次 bgsave 命令开始执行时间等等。
在这里插入图片描述
下面我们也粘贴粘贴源码，分析分析看 redis 是如何进行 RDB 备份文件生成的。

int serverCron(....){
    .....
    //如果已经有子进程在执行 RDB 生成，或者 AOF 恢复，或者有子进程未返回
    if (server.rdb_child_pid != -1 || server.aof_child_pid != -1 ||
        ldbPendingChildren())
    {
        int statloc;
        pid_t pid;
        //查看这个进程是否返回信号
        if ((pid = wait3(&statloc,WNOHANG,NULL)) != 0) {
            int exitcode = WEXITSTATUS(statloc);
            int bysignal = 0;

            if (WIFSIGNALED(statloc)) bysignal = WTERMSIG(statloc);
            //持久化异常，打印日志
            if (pid == -1) {
                serverLog(LL_WARNING,"wait3() returned an error: %s. "
                    "rdb_child_pid = %d, aof_child_pid = %d",
                    strerror(errno),
                    (int) server.rdb_child_pid,
                    (int) server.aof_child_pid);
            } else if (pid == server.rdb_child_pid) {
                //成功持久化 RDB 文件，调用方法用心的RDB文件覆盖旧的RDB文件
                backgroundSaveDoneHandler(exitcode,bysignal);
                if (!bysignal && exitcode == 0) receiveChildInfo();
            } else if (pid == server.aof_child_pid) {
                //成功执行 AOF，替换现有的 AOF文件
                backgroundRewriteDoneHandler(exitcode,bysignal);
                if (!bysignal && exitcode == 0) receiveChildInfo();
            } else {
                //子进程成功，但返回的 pid 类型异常，无法匹配
                if (!ldbRemoveChild(pid)) {
                    serverLog(LL_WARNING,
                        "Warning, detected child with unmatched pid: %ld",
                        (long)pid);
                }
            }
            //如果子进程未结束，不允许字典进行 rehash
            updateDictResizePolicy();
            closeChildInfoPipe();
        }
    } else{.......}
}

serverCron 每隔一百毫秒执行一次（可能后续的 redis 版本有所区别，本文基于 4.0），都会首先去判断 RDB 或 AOF 子进程是否成功完成，如果成功会进行旧文件替换覆盖操作等。我们继续看 else 部分。

int serverCron(....){
    .....
    if (server.rdb_child_pid != -1 || server.aof_child_pid != -1 ||
        ldbPendingChildren())
    {
        ..........
    }
    else{
        //如果未有子进程做 RDB 文件生成
        //遍历 saveparams 数组，取出我们配置文件中的 save 配置项
        for (j = 0; j < server.saveparamslen; j++) {
            struct saveparam *sp = server.saveparams+j;
            //根据我们之前介绍的 dirty 计数器判断 save 配置条件是否满足
            if (server.dirty >= sp->changes &&
                server.unixtime-server.lastsave > sp->seconds &&
                (server.unixtime-server.lastbgsave_try >
                 CONFIG_BGSAVE_RETRY_DELAY ||
                 server.lastbgsave_status == C_OK))
            {
                //记录日志
                serverLog(LL_NOTICE,"%d changes in %d seconds. Saving...",
                    sp->changes, (int)sp->seconds);
                rdbSaveInfo rsi, *rsiptr;
                rsiptr = rdbPopulateSaveInfo(&rsi);
                //核心方法，进行 RDB 文件生成
                rdbSaveBackground(server.rdb_filename,rsiptr);
                break;
            }
         }
         //AOF 下篇我们在介绍，本篇看 RDB
         if (server.aof_state == AOF_ON &&
             server.rdb_child_pid == -1 &&
             server.aof_child_pid == -1 &&
             server.aof_rewrite_perc &&
             server.aof_current_size > server.aof_rewrite_min_size)
         {
            long long base = server.aof_rewrite_base_size ?
                            server.aof_rewrite_base_size : 1;
            long long growth = (server.aof_current_size*100/base) - 100;
            if (growth >= server.aof_rewrite_perc) {
                serverLog(LL_NOTICE,"Starting automatic rewriting of AOF on %lld%% growth",growth);
                rewriteAppendOnlyFileBackground();
            }
         }
    }
}

如果未有子进程进行 RDB 文件生成，那么遍历循环我们的 save 配置项是否满足，如果满足则调用 rdbSaveBackground 进行真正的 RDB 文件生成。我们继续看看这个核心方法：

int rdbSaveBackground(char *filename, rdbSaveInfo *rsi) {
    pid_t childpid;
    long long start;

    if (server.aof_child_pid != -1 || server.rdb_child_pid != -1) return C_ERR;

    server.dirty_before_bgsave = server.dirty;
    server.lastbgsave_try = time(NULL);
    openChildInfoPipe();

    start = ustime();
    if ((childpid = fork()) == 0) {
        int retval;
        closeListeningSockets(0);
        redisSetProcTitle("redis-rdb-bgsave");
        retval = rdbSave(filename,rsi);
        if (retval == C_OK) {
            size_t private_dirty = zmalloc_get_private_dirty(-1);

            if (private_dirty) {
                serverLog(LL_NOTICE,
                    "RDB: %zu MB of memory used by copy-on-write",
                    private_dirty/(1024*1024));
            }

            server.child_info_data.cow_size = private_dirty;
            sendChildInfo(CHILD_INFO_TYPE_RDB);
        }
        exitFromChild((retval == C_OK) ? 0 : 1);
    } else {
        server.stat_fork_time = ustime()-start;
        server.stat_fork_rate = (double) zmalloc_used_memory() * 1000000 / server.stat_fork_time / (1024*1024*1024); /* GB per second. */
        latencyAddSampleIfNeeded("fork",server.stat_fork_time/1000);
        if (childpid == -1) {
            closeChildInfoPipe();
            server.lastbgsave_status = C_ERR;
            serverLog(LL_WARNING,"Can't save in background: fork: %s",
                strerror(errno));
            return C_ERR;
        }
        serverLog(LL_NOTICE,"Background saving started by pid %d",childpid);
        server.rdb_save_time_start = time(NULL);
        server.rdb_child_pid = childpid;
        server.rdb_child_type = RDB_CHILD_TYPE_DISK;
        updateDictResizePolicy();
        return C_OK;
    }
    return C_OK; 
}

rdbSaveBackground 核心的是 fork 函数和 rdbSave 函数的调用。fork 函数其实是一个系统调用，他会复制出一个子进程出来，子进程和父进程几乎一模一样的内存数据。

fork 函数是阻塞的，当子进程复制出来后，程序的后续代码段会由父子进程同时执行，也就是说，fork 之后，接下来的代码，父子进程会并发执行，但系统不保证执行顺序。

父进程中，fork 函数返回值等于子进程的进程 id，子进程中 fork 函数返回值等于零。

所以，rdbSaveBackground 函数的核心逻辑也就很清晰了，fork 成功之后，子进程调用 rdbSave 进行 RDB 文件写入，并产生一个“temp-%d.rdb”的临时文件，而父进程记录一些日志信息、子进程进程号，时间等信息。

至于 rdbSave 函数是怎么写入 RDB 文件的，这个也很简单，RDB 文件是有固定的协议规范的，程序只要按照协议写入数据即可，关于这个协议，我们等下详细说它。

总结一下，serverCron 这个定期执行的函数，会将配置文件中的 save 配置进行读取，并判断条件是否满足，如果条件满足则调用 rdbSaveBackground 函数 fork 出一个子进程完成 RDB 文件的写入，生成临时文件，并确保临时文件写入成功后，再替换旧 RDB 文件，最后退出子进程。

ps：fork 函数复制出来的子进程一定要记得退出，否则每一次主进程都会复制一个子进程，最终导致服务 OOM。

三、RDB 文件结构分析

任何格式的文件都会有自己的编码协议，Java 中的字节码也好、图片格式文件也好，我们这里的 RDB 文件也好，都是有自己的一套约定好的协议的，具体到每一个字节位置该放什么样的字段数据，这都是约定俗成的，编码的时候按协议写入二进制，读取的时候也按照协议读取字段字节。

RDB 协议规定整个文件包括如下几个字段：
RDB协议规范
其中，第一部分是固定的五个字节，redis 把它称为 Magic Number，固定的五个字符 “R”，“E”，“D”，“I”，“S”。
在这里插入图片描述
我们在 redis 的 0 号数据库中添加一个键值对，然后执行 save 命令生成 RDB 文件，接着打开这个二进制文件。
rdb二进制文件
我们用 od 命令，并以 ASCII 码选项输出二进制文件，你会发现前五个字节是我们固定的 redis 这五个字符。

下一个字段 REDIS_VERSION 占四个字节，描述当前 RDB 的版本，以上述为例，redis-4.0 版本对应的 RDB 文件版本就是 0008。

下一个字段是 Aux Fields，官方称辅助字段，是 RDB 7 以后加入的，主要包含以下这些字段信息：

  1. redis-ver：版本号
  2. redis-bits：OS Arch
  3. ctime：RDB文件创建时间
  4. used-mem：使用内存大小
  5. repl-stream-db：在server.master客户端中选择的数据库
  6. repl-id：当前实例 replication ID
  7. repl-offset：当前实例复制的偏移量

接着就是 DATABASE 部分，这部分会存储的我们字典中的真实数据，redis 中多个数据库，生成 RDB 文件的时候只会对有数据的数据库进行写入，而这部分的格式如下：
DATABASE数据格式
对应到我们上述例子中，就是这一部分：
DATABASE二进制数据
我们的 rdb.h 文件头中有这么一些常量的定义：

#define RDB_OPCODE_AUX        250
#define RDB_OPCODE_RESIZEDB   251
#define RDB_OPCODE_EXPIRETIME_MS 252
#define RDB_OPCODE_EXPIRETIME 253
#define RDB_OPCODE_SELECTDB   254
#define RDB_OPCODE_EOF        255

十六进制 fe 转换成十进制就是 254，对应的就是 RDB_OPCODE_SELECTDB，标识即将打开某数据库，所以其后跟着的就是即将要打开的数据库编号，我们这里是零号数据库。

十六进制 fb 转换成十进制就是 251，对应的就是 RDB_OPCODE_RESIZEDB，标识当前数据库容量，即有多少个键，我们这里只有一个键。

紧接着就是存我们的键值对，这部分的格式如下：
键值对存储格式
type 占一个字节标识当前键值对的类型，即对象类型，有如下可选类型：

#define RDB_TYPE_STRING 0
#define RDB_TYPE_LIST   1
#define RDB_TYPE_SET    2
#define RDB_TYPE_ZSET   3
#define RDB_TYPE_HASH   4
#define RDB_TYPE_ZSET_2 5 
#define RDB_TYPE_MODULE 6
#define RDB_TYPE_MODULE_2 7 
/* Object types for encoded objects. */
#define RDB_TYPE_HASH_ZIPMAP    9
#define RDB_TYPE_LIST_ZIPLIST  10
#define RDB_TYPE_SET_INTSET    11
#define RDB_TYPE_ZSET_ZIPLIST  12
#define RDB_TYPE_HASH_ZIPLIST  13
#define RDB_TYPE_LIST_QUICKLIST 14

key 始终是字符串，由字符串长度前缀加上自身内容构成，后跟 value 的内容。

  • EOF 字段标识 RDB 文件的结尾，占一个字节，并固定值等于 255 也就是十六进制 ff，这是能从 rdb.h 文件头中找到的。
  • CHECK_SUM 字段存储的是 RDB 文件的校验和，占八个字节，用于校验 RDB 文件是否损坏。

以上，我们就简单介绍了 RDB 文件的构成，其实也只是点到为止啊，每一种类型的对象进行编码的时候都是不一样的，还要一些压缩对象的手法等等，我们这里也不可能全部详尽。

总的来说，对 RDB 文件构成有个基本了解就行，实际上也很少有人没事去分析 RDB 文件里的数据的，即便是有也是通过工具进行分析的，比如 rdb-tools 等，人工分析也太炸裂了。

好了，关于 RDB 我们就简单介绍到这，下一篇我们研究研究 AOF 这种持久化策略，再见！

原文地址：https://www.cnblogs.com/yangming1996/p/12152090.html

ChaITSimpleLove
关注
专栏目录
Redis两种持久化方案RDB和AOF详解
09-09
RDB是Redis的默认持久化策略，它会在特定条件下生成数据的快照并保存到硬盘上，通常以`dump.rdb`文件的形式存在。RDB的主要配置在`redis.conf`文件的SNAPSHOTTING部分。例如，`save 900 1`表示如果在900秒内有至少一...
redis持久化之----RDB(Redis DataBase )
kfengqingyangk的博客
12-04 662
Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务 器。 Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以
Redis持久化策略
WuHuaSen的博客
09-07 2277
Redis是基于内存操作，作为一个数据库也具备持久化能力，但是为了实现高效的读写操作，并不会及时进行数据的持久化，而是按照一定的规则进行持久化操作的。
Redis——持久化策略
最新发布
m0_72165281的博客
09-21 1252
Redis——持久化策略
Redis（12）--Redis的持久化之RDB方式
一个人的江湖
03-15 337
RDB方式 Redis是默认支持的 优势：只有一个文件，时间间隔的数据，可以归档为一个文件，方便压缩转移（就一个文件）。 劣势：如果宕机，数据损失比较大，因为它是没一个时间段进行持久化操作的。也就是积攒的数据比较多，一旦懵逼，就彻底懵逼了。 配置如下： [root@localhost redis]# vi redis.conf 编辑redis.conf 往下拉： 这里save...
Redis（二十五）-持久化操作之RDB
码农飞哥
05-22 2247
rdb数据同步
stop-writes-on-bgsave-error
weixin_39472415的博客
08-18 2万+
redisRDB持久化配置 RDB持久化 配置 stop-writes-on-bgsave-error 选项 如果 = yes ： redis 会创建一个新的后台进程dump rdb。 假设 ：创建快照（硬盘上，产生一个新的rdb文件）需要 20s时间，redis主进程，在这20s内，会继续接受客户端命令，但是，就在这20s，内，创建快照！！！，出错了，比如磁盘满了，那么redis会认为， 当...
stop-writes-on-bgsave-error |Redis持久化相关问题
fhzmWJ的博客
07-28 1万+
目录 本来下午很困的，但是回车之后发现报错，就不困了。 是这样的我正准备往Redis里存储Key，然后： (error) MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk. Commands that may modify the data set are disabled, because this instance is configured to re
Redis持久化一一RDB
01-07
Redis会单独创建(fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能...
浅谈redis内存数据的持久化方式
01-21
一、概述 Redis的强大性能很大程度上都是因为所有数据都是存储在内存中的，然而当...Redis支持两种数据持久化方式：RDB方式和AOF方式。前者会根据配置的规则定时将内存中的数据持久化到硬盘上，后者则是在每次执行写
Redis 持久化之RDB和AOF.doc
10-09
Redis 持久化是确保数据安全的重要机制，它提供了两种主要的方法：RDB（Redis Database）和 AOF（Append Only File）。RDB 是一种快照式的持久化方式，而 AOF 则记录每次写操作的日志。 RDB 持久化在特定条件下将...
RDB 持久化详解
氷的博客
04-27 2031
Redis 是内存数据库，数据都是存储在内存中，为了避免进程退出导致数据的永久丢失，需要定期将 Redis 中的数据以某种形式（数据或命令）从内存保存到硬盘。当下次 Redis 重启时，利用持久化文件实现数据恢复。除此之外，为了进行灾难备份，可以将持久化文件拷贝到一个远程位置。Redis 的持久化机制有两种：RDB(Redis Data Base) 内存快照AOF(Append Only File) 增量日志。
Redis的持久化策略
2301_78418531的博客
07-03 754
Redis的数据全部存储在内存中，如果突然宕机，数据就会全部丢失，因此必须有一套机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的持久化机制，它会将内存中的数据库状态保存到磁盘中。
Redis持久化的几种方式——深入解析RDB_save 900 1 300 10 60 10000
2401_84264010的博客
04-17 866
RDB（Redis DataBase）是将某一个时刻的内存快照（Snapshot），以二进制的方式写入磁盘的过程。
Redis 持久化之 RDB 与 AOF 详解
ctrigger的专栏
09-21 424
整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。中断例程中，kernel就会把触发的异常的页复制一份，于是父子进程各自持有独立的一份。随着Redis的运行，AOF的日志会越来越长，如果实例宕机重启，那么重放整个AOF将会变得十分耗时，而在日志记录中，又有很多无意义的记录，比如我现在将一个数据 incr 一千次，那么就不需要去记录这1000次修改，只需要记录最后的值即可。
Redis的RDB持久化
Dou_Hua_Hua的博客
08-20 505
Redis是内存数据库，为了保证数据不在故障后丢失，Redis需要将数据持久化到硬盘上。 Redis持久化有两种方式:一种是快照，全量备份。一种是AOF方式，连续增量方式。 ##RDB RDB持久化就是把数据生成快照保存到硬盘的过程。每N分钟数据发送了M次写操作之后，从内存dump数据形成rdb文件，压缩后放在备份目录 ##工作原理 Redis-Server主进程会Fork一个子进程在后台生成RDB文件，主进程可以在不阻塞线程情况下接收其他命令。在主进程Fork过程中会产生阻塞，Fork完成后不在阻塞主进程
Redis - 8、持久化之RDB（Redis DataBase）
热门推荐
。
06-21 5万+
在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是键快照文件直接读到内存里。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值