rdb持久化通过fork子进程和写时复制（cow）机制实现：主进程fork后继续服务，子进程生成内存快照；cow确保子进程看到fork瞬间的一致性数据，修改时仅复制被写内存页；子进程写入临时文件后原子替换dump.rdb；save会阻塞主线程，生产环境必须使用bgsave。
RDB 持久化通过 fork 子进程实现快照，核心在于利用操作系统级的 写时复制（Copy-On-Write, COW） 机制，让主进程不中断服务，子进程安全生成内存快照。
fork 创建子进程的瞬间行为
当执行 bgsave 或满足自动触发条件时，Redis 主进程调用 fork() 系统调用：
- 子进程获得父进程内存页表的副本，但物理内存页仍与父进程只读共享
- 此时父子进程看到的是完全一致的内存数据，即“fork 那一刻”的状态
- fork 过程本身会短暂阻塞主线程（尤其在大内存实例中），但之后立即恢复响应
写时复制如何保障快照一致性
fork 后，主进程继续处理写请求，而子进程开始序列化数据。COW 机制确保快照不受干扰：
- 主进程修改某个 key 时，内核检测到该页为只读，触发缺页中断
- 内核为该页分配新物理内存，将原内容复制过去，再允许主进程写入
- 子进程始终读取原始物理页，看到的数据严格定格在 fork 时刻
- 内存开销仅发生在实际被修改的页上，而非全量复制
子进程完成快照的完整流程
子进程独立完成持久化，全程不干扰主进程：
- 遍历所有数据库和键值对，按 RDB 二进制格式序列化
- 写入临时文件（如
temp-123.rdb），避免写入失败破坏旧快照 - 写入完成后，用
rename()原子替换旧dump.rdb文件 - 子进程退出，临时文件清理，主进程无感知
为什么不能用 save 而必须用 bgsave
save 是同步阻塞操作，整个持久化过程由主进程亲自执行：
- 期间无法处理任何客户端命令，延迟可能达秒级甚至更长
- 大内存场景下，序列化 + 写磁盘完全占用主线程 CPU 和 IO
- 而
bgsave把耗时操作交给子进程，主进程只承担 fork 开销，生产环境唯一推荐方式
