RDB 快照的生命周期、磁盘文件管理、数据一致性问题

这涉及到 RDB 快照的生命周期、磁盘文件管理、数据一致性问题，也是很多人搞不清楚的细节，下面我来给你超清晰地解释一下：

 

---

 

 

✅ 你的问题可以拆解成两个部分：

 

 

 

1. Redis 如果前 900 秒保存了快照 A（比如 dump-a.rdb），

2. 又到了下一轮，触发了另一次快照保存，变成快照 B（dump-b.rdb）

   👉 那是不是就有两个存量了？那 A 文件还在吗？Redis 是怎么处理这些快照的？

 

 

---

 

 

✅ 正确答案：

 

 

不会同时保留多个 RDB 文件，Redis 始终只保留一个 RDB 文件（默认为 dump.rdb）

 

 

• 新的快照（B）会在后台 生成一个临时 RDB 文件

• 如果生成成功 ✅，它会 覆盖旧的 dump.rdb

• 如果生成失败 ❌，旧的文件继续保留，不会影响线上运行

 

 

---

 

 

🔁 举个实际的流程（RDB 快照更新逻辑）

 

 

1. 开始触发 BGSAVE

    

   • Redis fork 一个子进程

   • 在磁盘上生成一个临时文件，比如 temp-XXXX.rdb

    

2. 子进程写入快照完成

    

   • 校验文件完整性

    

3. 替换旧文件

    

   • Redis 将旧的 dump.rdb 删除或重命名

   • 把新生成的 temp-XXXX.rdb 重命名为 dump.rdb

    

4. 最终结果

    

   • 你仍然只有一个文件：dump.rdb，它就是最近一次快照的结果

    

 

 

---

 

 

🧠 所以你问的这个问题，可以这样理解：

 

时间点	RDB 文件状态
t=0，第一次 save	生成 dump.rdb（快照A）
t=900，再次 save	先写临时文件 → 校验成功 → 覆盖原 dump.rdb
t=1800	再次保存，重复上面流程

👉 所以你看到的文件始终是当前“最新快照”的快照文件，没有多个历史版本

 

---

 

 

✅ 补充一点（想保留历史快照怎么办？）

 

 

Redis 本身不会保留历史快照，但你可以用操作系统手动备份或定时拷贝 dump.rdb：

 

比如：

cp dump.rdb dump-20250417.rdb

也可以用脚本定时保留 7 天快照，滚动删除旧文件，很多企业就是这么干的。

 

---

 

 

🧠 总结一句话：

 

 

Redis 的 RDB 快照是全量备份文件，默认不会保留多个版本；

每次 BGSAVE 只会生成一个新的快照文件，成功后覆盖旧的 dump.rdb；

如果你想要多个历史版本快照，需要你自己定时拷贝备份 dump.rdb。