一句话答案

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

核心要点

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

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

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

AOF 重写（AOF Rewrite）：

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

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

• 快照存 RDB，快照后的增量写操作存 AOF
• 恢复时先加载 RDB，再重放 AOF 增量，速度快且数据丢失少

五、分布式锁

追问与易错

追问方向：

• 这个概念在你的项目中是怎么应用的？
• 和相关技术/方案相比有什么优劣？
• 如果出了问题你会怎么排查？

易错点：

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

💡 记忆锚点

RDB = 定时拍照（恢复快但两张照片之间的变化丢了），AOF = 实时录像（完整但文件大），混合持久化 = 先放一张照片再接着录（兼顾恢复速度和数据安全）。AOF刷盘记住everysec是生产默认值。