RDB持久化和AOF持久化：面试必考的Redis核心机制
2025年Java面试宝典：点我获取（提取码：9b3g）
一、为什么面试官总爱问Redis持久化？
面试中只要提到Redis，十有八九会追问RDB持久化和AOF持久化的区别。毕竟数据可靠性是分布式系统的命脉。想象一个场景：Redis突然宕机，内存数据全丢？这时候持久化机制就是救命稻草。今天我们就用程序员能听懂的大白话，拆解这两个核心机制。
二、RDB持久化：快照存盘术
RDB持久化的原理就像手机拍照——在某个瞬间把内存数据完整保存成二进制文件（dump.rdb）。触发方式有三：
- 手动SAVE命令（阻塞式，生产环境慎用！）
- BGSAVE命令（后台fork子进程操作，主流姿势）
- 配置文件定时策略（例如
save 900 1）
优点：
- 数据恢复速度极快（直接加载二进制文件）
- 文件紧凑，适合备份迁移
致命缺点：
- 可能丢失最后一次快照后的数据（取决于配置周期）
- fork子进程时如果数据量太大，会导致服务短暂卡顿
三、AOF持久化：操作日志流水账
如果说RDB持久化是拍照，那AOF持久化就是全程录像。它记录每一条写操作命令（如SET name "面试鸭"），通过重放日志恢复数据。工作流程分三步：
- 命令追加：写操作后追加到AOF缓冲区
- 文件同步：根据
appendfsync策略刷盘（always/everysec/no） - 日志重写：压缩冗余命令（BGREWRITEAOF触发）
优点：
- 数据丢失少（everysec策略最多丢1秒数据）
- 可读性强（文本格式方便排查问题）
痛点：
- 文件体积通常比RDB大
- 恢复速度慢（需要逐条执行命令）
四、混合持久化：鱼与熊掌兼得
Redis 4.0 推出了 AOF+RDB混合持久化（配置项aof-use-rdb-preamble yes）。原理很简单：
- 持久化时先写RDB格式的全量数据
- 后续增量数据用AOF格式追加
这样既保证恢复速度（直接加载RDB部分），又减少数据丢失风险（AOF补全增量）。面试时说出这个方案，绝对加分！
五、面试实战应答技巧
当被问到“RDB持久化和AOF持久化如何选型？”时，可以这样答：
“如果追求极限恢复速度且能容忍少量数据丢失（如缓存场景），选RDB持久化；
如果要求数据绝对安全（如金融交易），必须用AOF持久化；
而生产环境我通常启用混合模式，这是目前的最优解。”
高频追问：
-
Q：BGSAVE执行时还能写数据吗？
A：可以！父进程继续响应请求，子进程写RDB（Copy-On-Write机制） -
Q：AOF重写会阻塞吗？
A：不会。和BGSAVE一样走fork子进程流程
🔥 面试鸭会员福利：通过面试鸭返利网购买会员，立返25元！覆盖全网技术题库+实时更新，点击了解→ mianshiyafanli.com
六、总结
理解RDB持久化和AOF持久化的本质差异，关键在于抓住三个维度：
- 数据安全性：AOF > 混合 > RDB
- 恢复速度：RDB > 混合 > AOF
- 性能影响：RDB的fork风险 vs AOF的磁盘IO压力
实际开发中，记得在redis.conf里合理配置save规则和appendfsync策略，混合持久化真香！
