RDB 常被理解成“定时保存一份 dump 文件”，这句话没错，但它隐藏了最关键的工程成本：为了后台生成快照，Redis 需要 fork 子进程。
fork 后父子进程共享内存页。父进程继续处理写请求，一旦修改某些页，就会触发 Copy-On-Write，复制出新页。这就是大实例 BGSAVE 时内存尖刺和延迟抖动的来源。
先把机制边界说清楚
这一篇讨论 RDB 的快照机制和成本，不讨论 AOF 的追加日志。RDB 更适合备份和快速恢复基线，不适合把数据丢失窗口压到极小。
整体路径
上面这张图先把主线铺开：子进程写快照，父进程写入会复制被修改页。读 Redis 这类系统，最重要的是别只停在命令接口，要继续追问它在内存里是什么形状、在主线程上走多远、失败时会留下什么状态。
底层机制
BGSAVE通过 fork 子进程生成 RDB，父进程继续服务客户端。- fork 本身会复制页表，大内存实例上可能带来毫秒到秒级抖动。
- 快照期间写入越多，COW 复制出来的内存页越多。
- RDB 文件紧凑，适合备份、异地归档和冷启动恢复。
这些机制放在一起看，就能把「这个命令能不能用」改成「这个命令在当前数据规模下还便不便宜」。Redis 的很多坑，不是命令本身错了，而是数据规模和访问方式已经越过了它的舒适区。
取舍与边界
RDB 的优势是恢复基线清晰、文件小；弱点是有数据丢失窗口，并且快照期间会受 fork 和 COW 影响。
典型问题：用机制化例子排查
- 监控
latest_fork_usec、rdb_bgsave_in_progress和内存峰值。 - 大实例不要在写入高峰频繁 BGSAVE。
- 备份策略要覆盖文件转储、校验和恢复演练，不是只看 dump 是否生成。
- 容器环境要给 COW 峰值预留内存，避免快照期间 OOM。
收束：一句判断
RDB 的代价不在文件，而在 fork 那一刻之后的写入压力。
关于十三Tech
我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。
我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。
如果你想继续跟完这套「图解 Redis」，欢迎关注公众号 「十三Tech」。后续会继续按数据结构、底层机制、持久化、高可用和实战排查这条线更新。
