RDB 持久化是把当前进程数据生成快照保存到硬盘的过程, 触发 RDB 持久化过程分为手动触发和自动触发

5.1.1 触发机制

手动触发:

  • save: 阻塞当前 Redis 服务器, 直到 RDB 过程完成为止, 对于内存比较大的实例会造成长时间阻塞, 线上环境不建议使用
  • bgsave: Redis 进程执行 fork 操作创建子进程, RDB 持久化过程由子进程负责, 完成后自动结束。阻塞只发生在 fork 阶段, 一般时间很短

自动触发 RDB 的持久化机制, 例如以下场景:

  1. 使用 save 相关配置, 如 “save m n”。表示 m 秒内数据集存在 n 次修改时, 自动触发 bgsave。
  2. 如果从节点执行全量复制操作, 主节点自动执行 bgsave 生成RDB文件并发送给从节点, 更多细节见6.3节介绍的复制原理。
  3. 执行 debug reload 命令重新加载 Redis 时, 也会自动触发 save 操作。(不清楚是 save 还是 bgsave)
  4. 默认情况下执行 shutdown 命令时, 如果没有开启 AOF 持久化功能则自动执行 bgsave。

5.1.2 流程说明

image.png

5.1.3 RDB 文件的处理

保存: RDB 文件保存在 dir 配置指定的目录下, 文件名通过 dbfilename 配置指定。可以通过执行 config set dir {newDir} 和 config set dbfilename {newFileName} 运行期动态执行, 当下次运行时 RDB 文件会保存到新目录。

压缩: Redis 默认采用 LZF 算法对生成的 RDB 文件做压缩处理, 压缩后的文件远远小于内存大小, 默认开启, 可以通过参数 config set rdbcompression {yes|no} 动态修改。

校验: 如果 Redis 加载损坏 的RDB 文件时拒绝启动, 并打印如下日志:

  1. # Short read or OOM loading DB. Unrecoverable error, aborting now.

这时可以使用 Redis 提供的 redis-check-dump 工具检测 RDB 文件并获取对应的错误报告。

5.1.4 RDB 的优缺点

优点:

  • RDB 是一个紧凑压缩的二进制文件, 代表 Redis 在某个时间点上的数据快照。非常适用于备份, 全量复制等场景
  • Redis 加载 RDB 恢复数据远远快于 AOF 的方式

缺点:

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