我要评论redis 的 rdb 持久化，本质是通过生成内存数据的快照文件（.rdb）来保存数据，redis 重启时加载该文件即可恢复数据。
rdb 是 redis 默认的持久化方式，支持手动触发和自动触发两种模式，下面从核心机制、配置、操作步骤、恢复流程、优缺点等方面，详细说明如何使用 rdb 持久化。
一、rdb 持久化的核心原理
快照生成逻辑当触发 rdb 持久化时，redis 会执行以下步骤：
- redis 主进程
fork一个子进程（父子进程共享内存数据）； - 子进程遍历内存中的数据，将其写入到一个临时的 rdb 文件中；
- 子进程写入完成后，用临时文件替换旧的 rdb 文件（原子操作，保证文件完整性）；
- 子进程退出，主进程继续处理客户端请求。
关键：fork 操作会产生 ** 写时复制（copy-on-write）** 机制 —— 父子进程共享内存页，只有当主进程修改数据时，才会复制对应内存页，避免占用双倍内存。
rdb 文件特性
- 文件名默认是
dump.rdb，是二进制压缩文件，体积小，便于传输和备份； - 一个 rdb 文件包含某一时刻 redis 的全量数据快照，恢复时直接加载到内存，速度远快于 aof 持久化。
二、rdb 持久化的触发方式
rdb 有两种触发方式：手动触发（按需执行）和自动触发（配置规则自动执行）。
手动触发（常用）
手动触发有两个命令：save 和 bgsave，生产环境优先使用 bgsave。
| 命令 | 执行逻辑 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| save | 主进程直接生成 rdb 文件，阻塞所有客户端请求 | 无需 fork 子进程，无内存开销 | 阻塞 redis，期间无法处理命令 | 测试环境、数据量极小的场景 |
| bgsave | 主进程 fork 子进程生成 rdb 文件，主进程不阻塞 | 不影响 redis 正常服务 | fork 子进程会消耗内存（大内存实例 fork 较慢） | 生产环境、日常备份 |
实操示例
# 1. 手动执行 bgsave（推荐） 127.0.0.1:6379> bgsave background saving started # 提示：后台保存已启动 # 2. 查看 bgsave 执行状态（通过 info 命令） 127.0.0.1:6379> info persistence # persistence rdb_changes_since_last_save: 0 # 上次保存后数据变化量 rdb_bgsave_in_progress: 0 # 0=未执行，1=正在执行 rdb_last_save_time: 1719234567 # 上次保存的时间戳 rdb_last_bgsave_status: ok # 上次保存状态：ok=成功，err=失败
自动触发（配置规则）
通过修改 redis.conf 配置文件，设置数据变化触发条件，redis 会在满足条件时自动执行 bgsave。
核心配置项是 save <seconds> <changes>，格式为：save 时间窗口(秒) 数据变化次数，可以配置多个条件（满足任意一个即触发）。
配置示例（redis.conf）
# 900秒内至少1个键被修改 → 触发 bgsave save 900 1 # 300秒内至少10个键被修改 → 触发 bgsave save 300 10 # 60秒内至少10000个键被修改 → 触发 bgsave save 60 10000 # 禁用自动触发 rdb（注释所有 save 配置，或添加下面一行） # save ""
其他自动触发场景
- 执行
flushall命令：会清空所有数据，并生成一个空的dump.rdb文件（生产环境慎用）。 - 主从复制时：主节点首次向从节点同步数据时，会自动执行
bgsave生成 rdb 文件，发送给从节点。
三、rdb 持久化的核心配置（redis.conf）
除了 save 触发条件，redis.conf 中还有多个参数控制 rdb 的行为，关键配置如下：
| 配置项 | 作用 | 默认值 | 示例 |
|---|---|---|---|
| dbfilename | 指定 rdb 文件名 | dump.rdb | dbfilename redis_6379.rdb（按端口命名，便于区分多实例） |
| dir | 指定 rdb 文件的保存目录（必须是目录，不是文件名） | .（当前目录） | dir /var/lib/redis（推荐配置独立目录） |
| rdbcompression | 是否压缩 rdb 文件（lzf 压缩算法） | yes | rdbcompression yes（压缩后文件更小，略增加 cpu 开销） |
| rdbchecksum | 是否对 rdb 文件做校验和（crc64 算法），保证文件完整性 | yes | rdbchecksum yes（加载时校验，略增加 cpu 开销） |
配置生效步骤
修改 redis.conf 后，重启 redis 生效：
redis-server /etc/redis/redis.conf
验证配置：
127.0.0.1:6379> config get dbfilename 1) "dbfilename" 2) "redis_6379.rdb" 127.0.0.1:6379> config get dir 1) "dir" 2) "/var/lib/redis"
四、rdb 持久化的数据恢复流程
redis 重启时会自动加载 rdb 文件恢复数据，无需手动操作，恢复流程如下：
- redis 启动时，检查
dir配置的目录下是否存在dbfilename指定的 rdb 文件； - 如果存在，加载 rdb 文件到内存；如果不存在，启动后数据为空；
- 加载完成后，redis 开始接受客户端请求。
注意：如果 redis 同时开启了 aof 持久化，则会优先加载 aof 文件（因为 aof 数据的实时性更高）。
验证数据恢复
手动执行 bgsave 生成 rdb 文件：
127.0.0.1:6379> set name tom # 写入测试数据 ok 127.0.0.1:6379> bgsave background saving started
停止 redis：
redis-cli shutdown
重启 redis，查看数据是否恢复：
redis-cli 127.0.0.1:6379> get name "tom" # 数据成功恢复
五、rdb 持久化的优缺点
优点
- 恢复速度快：rdb 是全量快照文件，redis 重启时直接加载到内存，比 aof 逐行重放命令快得多。
- 文件体积小：二进制压缩格式，便于备份、归档和传输（适合用于定时备份）。
- 对主进程影响小：
bgsave由子进程执行，主进程可以正常处理请求。
缺点
- 数据安全性低：rdb 是周期性快照，两次快照之间的数据会丢失（比如设置
save 900 1，如果 redis 崩溃，最多会丢失 15 分钟的数据）。 - 大内存实例开销大：
fork子进程时，会复制主进程的内存页表，大内存实例（如 10gb 以上）fork耗时较长，期间 redis 可能出现短暂卡顿。 - 无法实时持久化：不适合对数据实时性要求高的场景（如金融交易）。
六、rdb 持久化的最佳实践（生产环境）
- 配合 aof 使用：开启 rdb+aof 混合持久化（redis 4.0+ 支持），兼顾 rdb 的恢复速度和 aof 的数据安全性。
- 合理配置
save参数：避免过于频繁触发bgsave（如不要设置save 10 1），防止fork操作频繁消耗资源；也不要设置太宽松（如save 3600 1），避免数据丢失过多。 - 定期手动备份 rdb 文件：通过
bgsave生成 rdb 文件后，复制到其他服务器或云存储（如 s3），作为灾难恢复的备份。 - 控制 redis 内存大小：避免 redis 内存过大（如超过 10gb），减少
fork时的内存开销和卡顿时间。 - 监控
fork耗时：通过info stats查看latest_fork_usec（上次fork耗时，单位微秒），如果耗时过长（如超过 1 秒），需要优化内存或调整持久化策略。
总结
rdb 持久化是 redis 的基础持久化方式，核心是通过快照文件保存全量数据，使用时需注意：
- 手动触发用
bgsave，避免save阻塞主进程； - 自动触发通过
redis.conf的save参数配置，平衡性能和数据安全性； - 恢复时 redis 自动加载 rdb 文件，aof 开启时优先加载 aof；
- 生产环境建议 rdb+aof 混合持久化，兼顾速度和安全性。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持代码网。
发表评论