Redis（二）：RDB 持久化

忘是亡心i 2022-02-02 12:21 301阅读 0赞

### 文章目录 ###

*   *  1、RDB 持久化触发方式
     *   *  1.1、RDB 持久化手动触发
         *   *  1.1.1、save 命令
             *  1.1.2、bgsave 命令
         *  1.2、RDB 持久化自动触发
     *  2、RDB 持久化流程
     *  3、RDB 持久化文件
     *   *  3.1、RDB 文件的加载
         *  3.2、RDB 文件结构
     *  4、RDB 持久化优缺点
     *   *  4.1、RDB 的优点
         *  4.2、RDB 的缺点
     *  5、RDB 自动保存
     *   *  5.1、RDB 自动保存原理

Redis 支持 RDB 和 AOF 两种持久化机制，持久化机制有效地避免了数据丢失问题，当重启时，根据之前的持久化文件即可实现数据的恢复。

## 1、RDB 持久化触发方式 ##

RDB 持久化是把当前进程数据生成快照保存到硬盘的过程，有两种方式可以触发RDB 持久化，分别是 手动触发和自动触发

### 1.1、RDB 持久化手动触发 ###

手动触发命令有两个，分别是 save 和 bgsave

#### 1.1.1、save 命令 ####

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

save 命令执行时，会看到如下日志：

1:M 11 May 2019 04:26:19.927 * DB saved on disk

#### 1.1.2、bgsave 命令 ####

Redis 进程执行 fork 操作创建子进程，RDB 持久化过程由该子进程负责完成。阻塞只发生在 fork 阶段，时间很短，在此期间会 block 父进程不能及时响应请求。

bgsave 命令执行时，会看到如下日志：

1:M 11 May 2019 04:27:07.734 * Background saving started by pid 23
    23:C 11 May 2019 04:27:07.738 * DB saved on disk
    23:C 11 May 2019 04:27:07.739 * RDB: 6 MB of memory used by copy-on-write
    1:M 11 May 2019 04:27:07.818 * Background saving terminated with success

在 bgsave 命令执行期间，客户端发送的 sava 命令会被拒绝，服务其禁止 save 命令和 bgsave 命令同时执行，是为了避免父进程和子进程同时调用 rdbSave ，防止产生竞态条件。

> Redis 内部涉及 RDB 的操作都采用 bgsave 方式，而 save 命令已经废弃

### 1.2、RDB 持久化自动触发 ###

Redis 内部在某些场景下会自动触发 RDB 的持久化机制，如下：

1、配置文件中使用了 save 相关配置，eg：save m n 表示 m 秒内，修改了 n 次数据时，自动触发 bgsave。

2、集群情况下，从节点执行全量复制操作时，主节点会自动执行 bgsave 生成 RDB 文件并发送给从节点。

3、当执行 debug reload 命令重新加载 Redis 时，也会自动触发 save 操作。

4、默认情况下执行 shutdown 命令时，如果没有开启 AOF 持久化功能则会自动触发 bgsave

## 2、RDB 持久化流程 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70]

1、执行 bgsave 命令，Redis 父进程判断当前是否存在正在执行的子进程（RDB或AOF），如果存在 bgsave 命令直接返回。

2、父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，一般是毫秒级的，阻塞时间很短。可以通过 info stats 命令查看最近一次 fork操作的耗时（latest\_fork\_usec），单位是微秒

3、父进程fork完成后，bgsave 命令会返回“ Background saving started ”信息，然后就不再阻塞父进程，接着可以继续响应其它命令了。

4、子进程创建 RDB 文件，根据父进程内存生成临时快照文件，完成后对原有文件进行原子操作替换。可以通过 info stats 或 lastsave 命令查看最近一次生成 RDB 的时间（rdb\_last\_save\_time）

5、子进程创建 RDB 文件后，会发送信号给父进程表示持久化完成，然后父进程更新统计信息

## 3、RDB 持久化文件 ##

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

因为 RDB 文件时保存在硬盘中的，所以即便 Redis 服务进程退出 或服务器停机，只要 RDB 文件存在，Redis 服务就可以用它来还原数据库状态。

### 3.1、RDB 文件的加载 ###

RDB 文件的载入是在 Redis 服务启动时自动执行的，所以并没有专用于载入 RDB 文件的命令。只要 Redis 服务启动时检测到 RDB 文件存在，它就会自动载入 RDB 文件。

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

因为 AOF 文件的更新频率通常比 RDB 文件的更新频率高，所以持久化文件的加载会有以下情况值得注意：

*  如果Redis服务开启了AOF 持久化功能，会优先使用 AOF 文件还原数据库状态。
 *  如果Redis服务关闭了AOF 持久化功能，则会使用 RDB 文件来还原数据库状态。

Redis 服务判断用哪个文件还原数据库状态的流程如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 1]

### 3.2、RDB 文件结构 ###

一个完整的 RDB 文件会包含以下几个部分

<table> 
 <thead> 
  <tr> 
   <th>redis</th> 
   <th>db_version</th> 
   <th>databases</th> 
   <th>eof</th> 
   <th>check_sum</th> 
  </tr> 
 </thead> 
 <tbody></tbody> 
</table>

**redis:**

RDB 文件的开头是 redis 部分， 这个部分的长度为5字节，保存着“ redis” 五个字符。 通过这五个字符，程序可以在载入文件时，快速检查所载入的文件是否 RDB 文件。

**db\_version:**

db\_version 长度为 4 字节，它的值是一个字符串表示的整数，这个整数记录了 RDB 文件的 版本号。

**databases:**

databases 部分包含零个或多个数据库，以及各个数据库中的键值对数据。

*  如果数据库为空，那么这个部分也为空，长度为0字节
 *  如果数据库不为空，数据库所保存键值对的数量、类型和内容不同，这个部分的长度也会有所不同

**eof:**

EOF 常量的长度为 1 字节，这个常量标志着 RDB 文件正文内容的结束，当读入程序遇到这个 值的时候，它就认为所有数据库的所有键值对都已经载入完毕了。

**check\_sum:**

check\_sum 是一个长度为 8 字节的无符号整数，保存着一个校验和，这个校验和是根据前四个部分的内容进行计算得出的。Redis 服务在载入 RDB 文件时，会将载入数据所计算出的校验和与 check\_sum 所记录的值进行比较，以此来检查 RDB 文件是否错误或者损坏。

## 4、RDB 持久化优缺点 ##

### 4.1、RDB 的优点 ###

1）RDB 是一个紧凑压缩的二进制文件，代表 Redis 服务在某个时间点的数据快照。非常适用于备份、全量复制等场景。

2）Redis 服务加载 RDB 文件速度远远优于 AOF 的方式

### 4.2、RDB 的缺点 ###

1）RDB 方式 数据 没 办法 做到 实时 持久 化/ 秒 级 持久 化。 因为 bgsave 每次 运行  
运行 都要 执行 fork 操作 创建 子 进程， 属于 重量级 操作， 频繁 执行 成本 过高。 ·RDB 文件 使用 特定 二进制 格式 保存， Redis 版本 演进 过程 中有 多个 格式 的 RDB 版本， 存在 老 版本 Redis 服务 无法 兼容 新版 RDB 格式 的 问题。 针对 RDB 不适合 实时 持久 化 的 问题， Redis 提供 了 AOF 持久 化 方式 来 解决。

2）RDB 文件使用二进制格式保存，Redis 版本演进过程中有多种格式的RDB 版本，因此存在老版本 Redis 无法兼容新版Redis 的RDB 格式的文件。针对 RDB 不适合实时持久化的问题，Redis 提供了 AOF 持久化方式来解决这个问题。

## 5、RDB 自动保存 ##

我们可以通过设置配置文件中的 save 选项来配置多个保存条件，只要其中任意一个条件满足，Redis 服务就会执行 bgsave 命令。

举例说明，如下配置：

save 900 1
    save 300 10
    save 60 10000

只要满足三个条件中的任意一个，bgsave 命令就会被执行：

*  在 900 秒（15分钟）内，对数据库至少修改了 1 次
 *  在 300 秒（5分钟）内，对数据库至少修改了 10 次
 *  在 60 秒（1分钟）内，对数据库至少修改了 10000 次

### 5.1、RDB 自动保存原理 ###

当 Redis 服务器 启动 时， 用户 可以 通过 指定 配置文件 或者 传入 启动 参数 的 方式 设置 save 选项， 如果 用户 没有 主动 设置 save 选项， 那么 服务器 会为 save 选项 设置 默认 条件：

当 Redis 服务器启动时，我们可以通过指定配置文件或传入启动参数来设置 save 选项，如果没有设置 save 选项，那么 Redis 服务会使用默认条件：

save 900 1
    save 300 10
    save 60 10000

然后 Redis 服务会根据 save 选项，设置服务状态 redisServer 的 saveparams 属性：

struct redisServer { 
        // ...
        // 记录 save 条件的数组
        struct saveparam *saveparams; 
        // ... 
    };

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

struct saveparam { 
        // 秒数 
        time_t seconds; 
        // 修改次数 
        int changes; 
    };

除了 saveparams 数组之外，redisServer 还维护着一个 dirty 计数器 和 lastsave 属性：

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

struct redisServer { 
        // ...
        // 记录 save 条件的数组
        struct saveparam *saveparams; 
        // 记录修改次数
        long long dirty;
        // 记录上一次持久化时间
        time_t lastsave;
        // ... 
    };

当成功执行一个数据库修改命令之后，程序就会对 dirty 计数器 和 lastsave 时间戳进行更新。

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

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70]: /images/20220202/3498cf79e40d4be1abc63a446c091475.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3UwMTA2NDcwMzU_size_16_color_FFFFFF_t_70 1]: /images/20220202/bd172d762fcf4d9591c3c57bf889a95f.png