第四篇：RDB与AOF持久化——宕机后数据怎么恢复？

前言

在前三篇文章中，我们拆解了Redis的数据结构、内存管理和缓存三大问题。但还有一个根本性问题没有解决：Redis是内存数据库，数据存在内存中。一旦宕机，内存中的数据全部丢失。

这就是Redis持久化要解决的问题。面试中，这个问题是必考题：

“RDB和AOF有什么区别？”
“为什么生产环境要同时开RDB和AOF？”
“AOF重写是什么？为什么要重写？”

本文从RDB的Copy-On-Write原理出发，拆解AOF的三种刷盘策略，最后落到生产环境的最佳配置方案。

本文核心问题：

1. RDB的工作原理是什么？bgsave为什么用fork而不是新建线程？
2. Copy-On-Write在RDB中是怎么体现的？
3. AOF的三种刷盘策略各有什么优劣？生产环境选哪个？
4. AOF重写是什么？为什么要重写？什么时候触发？
5. RDB和AOF各自的优劣？为什么生产环境要同时开？
6. RDB+AOF混合模式是怎么工作的？

读完本文，你将对Redis的持久化机制拥有从原理到配置的完整理解。

一、为什么需要持久化？

疑问：Redis不是缓存吗？数据丢了重新加载不就行了？

回答：Redis不只是缓存。它常被用作分布式锁、消息队列、计数器、Session存储——这些数据丢了不只是"多查一次数据库"，而是可能导致业务逻辑错误。

场景一：Redis做分布式锁 宕机 → 锁全部丢失 → 多个线程可能同时获得同一把锁 → 超卖 场景二：Redis做库存计数器 宕机 → 扣减记录全部丢失 → 已售库存回退 → 数据不一致 场景三：Redis做Session存储 宕机 → 所有用户登录状态丢失 → 大量用户被迫重新登录

持久化的本质：把内存数据备份到磁盘。宕机后重启，从磁盘恢复数据到内存。Redis提供两种持久化方式——RDB（快照）和AOF（追加日志），各有优劣，生产环境通常两者配合使用。

二、RDB——内存快照

疑问：RDB是什么？它是怎么工作的？

回答：RDB是某个时间点的内存全量快照。就像给内存拍一张照片，宕机后从这张照片恢复数据。

2.1 save vs bgsave

生产环境绝对不能用save——生成快照期间Redis完全不响应，如果内存有10GB，阻塞时间可能长达数十秒。bgsave通过fork子进程将写盘工作交给子进程处理，主线程只在fork的瞬间有短暂的停顿。

2.2 bgsave的工作流程

1. 主线程收到bgsave命令 2. 主线程调用fork()创建子进程 3. fork期间主线程短暂阻塞（通常微秒到毫秒级，取决于系统负载） 4. fork完毕 → 主线程继续处理客户端命令 5. 子进程遍历整个内存空间 → 写RDB文件 6. 子进程完成 → 通知主线程 → 子进程退出

关键操作：fork通过Copy-On-Write机制让子进程和父进程共享同一块物理内存，不需要复制整个内存空间。

2.3 Copy-On-Write——fork为什么高效

fork之后，父子进程共享同一块物理内存。操作系统将内存页标记为只读。当主线程需要修改某个内存页时，CPU触发写保护异常，操作系统为这个页创建一个副本给主线程写入，原来的页仍属于子进程用于快照。子进程读取的是fork那一刻的"冻结快照"，主线程继续写入不影响快照的完整性。

fork时刻： 父进程内存页A：[值=100] ← 父子共享 主线程执行 SET key 200： 操作系统复制页A → 页A'(副本) 父进程写页A'：[值=200] 子进程读页A：[值=100] ← 冻结在fork时刻 关键： 只有被修改的页才会复制（Copy-On-Write） 没有被修改的页仍然共享 所以fork不消耗内存，后续主线程写入时按页粒度复制

fork的优势：高效利用内存、不阻塞主线程、快照数据天然一致。代价是如果主线程在生成快照期间大量写入，Copy-On-Write导致的额外内存开销会增长——所有被修改的页都要复制一份。

2.4 RDB的触发方式

三、AOF——追加写入日志

疑问：RDB是全量快照，AOF是什么？

回答：AOF是增量日志——记录每一次写操作，重启时按顺序重放这些命令来恢复数据。

3.1 AOF的工作流程

1. 客户端执行 SET key value 2. Redis执行这个命令（修改内存中的数据） 3. Redis将这条命令追加到AOF缓冲区 4. AOF缓冲区根据刷盘策略写入磁盘文件

AOF文件中的内容：

*3 $3 SET $3 key $5 value

3.2 三种刷盘策略

appendfsync配置控制AOF何时写入磁盘：

生产环境选everysec：丢1秒数据在绝大多数场景下可接受，而always的磁盘等待对Redis性能惩罚太大——每次写入都等待磁盘操作完成，Redis的单线程模型意味着这段时间内其他所有命令都被阻塞。no不保证数据何时落盘，操作系统级别的写延迟可能从几十毫秒到几秒不等，宕机时丢失的数据量完全不可控。

3.3 AOF重写——解决日志膨胀问题

问题：AOF记录每条写命令，日积月累文件越来越大。一个计数器被INCR了1000次，AOF中就记录1000条INCR。重启后重放1000条命令来恢复一个计数器，效率极低。

解决：AOF重写——根据当前内存状态，生成最小的写命令集合。

重写前AOF（1000条）： INCR counter INCR counter INCR counter ...（1000次） 重写后AOF（1条）： SET counter 1000

重写过程：

1. Redis fork一个子进程
2. 子进程根据当前内存状态生成新的AOF文件
3. 主线程在重写期间的写操作，同时记录到旧的AOF缓冲区和重写缓冲区
4. 子进程完成重写 → 将重写缓冲区中的增量追加到新AOF文件
5. 用新AOF文件替换旧AOF文件

触发条件：

auto-aof-rewrite-percentage 100 # AOF文件增长超过100%时触发重写 auto-aof-rewrite-min-size 64mb # AOF文件至少64MB才考虑重写

四、RDB vs AOF

五、为什么生产环境要同时开？

疑问：既然各有优劣，为什么不用一个最好的方案？

回答：两者互补——RDB用于快速恢复，AOF用于数据安全。同时开RDB和AOF，相当于有了"整点快照+分钟级日志"的双重保险。

场景一：Redis正常重启 → 用AOF恢复（数据最新，一条不丢） 场景二：AOF文件损坏（磁盘坏道） → 用RDB恢复（最近5分钟的快照，比全部丢失强） 场景三：从备份恢复数据到新集群 → 用RDB快速恢复全量数据，AOF补充增量 场景四：AOF体积过大影响重启速度 → 用RDB提供基准，AOF只记录RDB之后的增量

混合持久化（Redis 4.0+）：

RDB做全量快照，AOF做增量改进。RDB解决了"恢复慢"的问题（全量数据直接加载），AOF解决了"数据全"的问题（RDB时刻之后到当前的所有增量都被记录，不会丢失上次RDB之后的数据）。

六、生产环境的最佳配置

# redis.conf # 开启RDB save 900 1 # 900秒内至少1次修改 → 触发bgsave save 300 10 # 300秒内至少10次修改 → 触发bgsave save 60 10000 # 60秒内至少10000次修改 → 触发bgsave # 开启AOF appendonly yes appendfsync everysec # 每秒刷盘 auto-aof-rewrite-percentage 100 auto-aof-rewrite-min-size 64mb # 开启混合持久化 aof-use-rdb-preamble yes # AOF文件前半部分是RDB快照，后半部分是增量命令

混合持久化的工作方式：重写AOF时，先把当前内存数据以RDB格式写入AOF文件前半部分，再把重写期间的增量命令以AOF格式追加在后。重启时先快速加载RDB，再重放增量AOF。既有了RDB的快速恢复能力，又有了AOF的完整性保证。

总结

• RDB是内存全量快照，bgsave通过fork子进程+Copy-On-Write实现不阻塞主线程的写盘操作。快照间有丢失窗口
• AOF是增量日志，记录每次写操作。三种刷盘中everysec是性能和安全的最优折中——丢1秒数据可接受，磁盘同步的开销也可控
• AOF重写不阻塞主线程——fork子进程生成最小化的新AOF文件，替代旧AOF，解决日志膨胀问题
• 生产环境必须同时开：RDB做整点的快速恢复基准，AOF做分钟级的增量数据保护。两者互补，宕机后可用最近的备份组合恢复
• 混合持久化：RDB+增量AOF的组合方式兼得RDB的恢复速度和AOF的完整性，是最高效的生产配置
• 持久化策略的选择最终由恢复时间目标和数据丢失容忍度两个阈值决定：能接受丢多少数据、能接受恢复花了多久

下一篇预告：Redis原理（五）——主从复制与哨兵机制：Redis高可用的基石。拆解全量复制与部分复制的原理、主观下线和客观下线的区别、哨兵集群的选主过程，以及和Cluster的关系。