Java面试——Redis持久化RDB与AOF对比

RDB适合定时备份、从节点初始化同步及恢复速度优先且可容忍分钟级数据丢失的场景，但不适用于订单支付等强一致性业务。

Redis RDB 持久化到底适合什么场景

RDB 是通过 fork 子进程生成 dump.rdb 快照文件，适合做冷备和灾难恢复，但不是实时持久化方案。它天然适合定时备份、集群从节点初始化同步、以及对恢复速度要求高、能容忍几分钟数据丢失的业务。

常见误用是把它当唯一持久化手段部署在订单、支付类系统中——一旦宕机且上次 save 是 15 分钟前，就真丢了 15 分钟数据。

• save 900 1 表示 900 秒内至少 1 次写入才触发快照，低频写入场景下可能长期不落盘
• fork 耗时与 Redis 实例内存大小强相关：10GB 内存实例 fork 可能卡主进程 100ms+，线上需监控 latest_fork_usec
• RDB 文件是二进制压缩格式，不能像 AOF 那样用 cat 或 grep 直接查看内容，调试困难

AOF 重写（rewrite）为什么经常导致内存飙升

AOF 重写不是“复制旧日志”，而是由子进程读取当前内存数据，重新生成一条条等效命令写入新 appendonly.aof。这个过程会额外占用一块与当前数据集等大的内存空间（用于构建重写缓冲区 + 子进程页表）。

比如 Redis 使用了 4GB 内存，AOF 重写期间 RSS 很可能冲到 7–8GB，若机器只剩 2GB 空闲内存

，就会触发 OOM Killer 杀掉 redis-server。

• 重写是否触发取决于 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size，建议把后者设为 64mb 以上，避免小文件频繁重写
• aof-rewrite-incremental-fsync yes 必须开启，否则重写时所有写都积压在 page cache，一次性刷盘易打爆磁盘 I/O
• 重写期间新写入命令仍会同时写入老 AOF 文件和重写缓冲区，所以 bgrewriteaof 并发执行时要小心缓冲区溢出

RDB + AOF 混合使用时加载顺序和风险点

Redis 4.0+ 支持 aof-use-rdb-preamble yes，此时 AOF 文件开头是一段 RDB 格式数据，后面才是追加的命令。启动时只加载这一个文件，不再先载 RDB 再回放 AOF —— 这是性能关键优化。

但混合模式下最容易踩的坑是：手动替换 AOF 文件后忘记重命名或权限不对，Redis 启动时检测到 appendonly.aof 存在但无法读取，会静默退回到仅加载 RDB（如果有的话），结果就是“以为开了 AOF，其实没生效”。

• 检查是否真正启用混合模式：启动后执行 CONFIG GET aof-use-rdb-preamble，返回值必须是 yes
• 用 redis-check-aof --fix 修复损坏 AOF 时，它只会修尾部命令部分，不会碰前面的 RDB preamble，修完记得 cat 前 100 字节确认仍有 Redis RDB magic header（REDIS0009）
• 如果关闭了 RDB 但开启了 AOF，又设置了 aof-use-rdb-preamble no，那 AOF 文件体积会随时间线性增长，务必配好重写策略

面试常问：AOF everysec 模式为什么最多丢 2 秒数据

不是“每秒刷一次盘”就等于“最多丢 1 秒”，而是因为 write(2) 和 fsync(2) 是分离的：appendfsync everysec 表示 Redis 主线程每秒调用一次 write 把日志写入内核 buffer，后台线程再负责 fsync 刷盘。

但如果主线程某次 write 完还没等到后台线程 fsync，实例就崩溃了，这部分刚 write 进 buffer 但未 fsync 的数据就丢了。而两次 fsync 最大间隔接近 2 秒（例如上一次在 00:00:00.999，下一次在 00:00:02.001）。

• 极端情况下，Linux kernel 的 dirty_ratio 设置过高（如 40%），会导致 write buffer 长期不刷，实际丢失可能远超 2 秒
• appendfsync always 看似安全，但每次写都 fsync，QPS 跌 5–10 倍，SSD 寿命也会明显下降
• 生产环境推荐 everysec + 配合高可靠硬件（UPS、RAID 电池保护写缓存），而不是盲目切 always

# 示例：如何验证当前 AOF 是否启用了 RDB preamble
$ strings /var/lib/redis/appendonly.aof | head -c 20
REDIS0009*1\r\n$8\r\nselect\r\n$1\r\n0\r\n

RDB 和 AOF 不是二选一的选择题，而是数据可靠性、恢复速度、运维成本之间的权衡。真正容易被忽略的是：AOF 重写时的内存放大、混合模式下文件损坏的静默降级、以及 everysec 在内核 buffer 满时的行为漂移。这些细节往往比背对比表格更能暴露真实经验。