面试知识库
极高 进阶

Redis持久化RDB与AOF#

一句话答案#

RDB 定时全量快照（fork+COW，恢复快但可能丢数据），AOF 追加写命令（数据安全但文件大），混合持久化兼顾两者。

核心要点
维度RDB（快照）AOF（日志）
原理定时将内存数据生成二进制快照文件记录每条写命令（追加到 AOF 文件）
文件大小小（二进制压缩）大（文本命令，可重写压缩）
恢复速度快（直接加载快照）慢（重放所有命令）
数据丢失多（两次快照之间的数据丢失）少（默认每秒同步，最多丢 1s 数据）
写性能影响低（fork 子进程，异步）中（每次写命令追加 AOF）
适用场景灾难恢复，可接受分钟级数据丢失生产环境，要求少丢数据

AOF 的三种刷盘策略（appendfsync）：

appendfsync always      # 每条命令立即 fsync → 最安全，最慢
appendfsync everysec    # 每秒 fsync（默认） → 最多丢 1s 数据，推荐
appendfsync no          # 由 OS 决定何时 fsync → 最快，可能丢较多数据
bash

AOF 重写（AOF Rewrite）：

  • AOF 文件随时间越来越大（记录每次写命令）
  • Redis 定期执行 AOF 重写：fork 子进程，基于当前内存状态生成等价的最小命令集
  • 例：100 次 INCR → 重写为 1 条 SET（最终值）

Redis 6.2 推荐：RDB + AOF 混合持久化

  • 快照存 RDB，快照后的增量写操作存 AOF
  • 恢复时先加载 RDB，再重放 AOF 增量，速度快且数据丢失少
面试回答（2分钟版）

Redis持久化有RDB和AOF两种机制。RDB是定时生成内存的全量二进制快照，通过fork子进程利用COW机制写盘，对主线程影响小，恢复速度快，但两次快照之间的数据会丢失。AOF是把每条写命令追加到日志文件，默认配置appendfsync everysec每秒刷盘一次，最多丢1秒数据，比RDB安全得多，但AOF文件会越来越大，恢复时需要重放所有命令所以比较慢。为了解决AOF膨胀问题，Redis会执行AOF重写，fork子进程基于当前内存状态生成最小等价命令集，比如100次INCR重写为1条SET。生产环境推荐Redis 4.0之后的混合持久化方案，重写时先写RDB格式的全量数据，后面追加增量AOF命令，恢复时先加载RDB再重放增量AOF，兼顾了恢复速度和数据安全性。

追问与易错

追问方向：

  • “这个概念在你的项目中是怎么应用的？”→ 生产环境开启混合持久化（aof-use-rdb-preamble yes），AOF 刷盘策略用 everysec 平衡性能和安全；定时 RDB 快照用于灾备恢复和从库初始化
  • “和相关技术/方案相比有什么优劣？”→ RDB 恢复快但丢数据多，AOF 数据安全但恢复慢文件大；混合持久化兼顾两者优势；对比 MySQL 的 redo log（物理日志+WAL）和 binlog（逻辑日志），思路类似但 Redis 更简单
  • “如果出了问题你会怎么排查？”→ RDB 失败查 rdb_last_bgsave_status 和日志，通常是磁盘空间不足或 fork 内存不够；AOF 重写抖动查 aof_rewrite_in_progress，fork 大内存实例耗时长考虑减小实例内存或升级硬件

易错点：

  • ❌ 只知道概念不知道原理——面试官会追问底层实现
  • ❌ 缺乏实际使用经验——结合项目场景回答更有说服力