八股文解析
Redis 持久化：RDB 与 AOF 怎么选？
Redis 持久化：RDB 与 AOF 怎么选？
一句话结论
- RDB：定时快照，恢复快、文件紧凑，但可能丢最近几分钟数据
- AOF：追加命令日志，数据更安全，但文件大、恢复慢
- 生产建议：开混合持久化（AOF 重写时用 RDB 格式），或至少 AOF + everysec
面试标准答法
RDB（Redis Database）
在指定时间间隔内生成数据集的快照（snapshot），保存为 dump.rdb。
触发方式：
SAVE：同步阻塞，生产禁用BGSAVE：fork 子进程异步执行，常用- 配置自动触发：
save 900 1/save 300 10/save 60 10000
优点：
- 文件紧凑，适合备份和灾难恢复
- 恢复速度比 AOF 快
- 对性能影响小（fork 后子进程处理）
缺点：
- 最后一次快照后的数据可能丢失
- fork 时内存翻倍风险（大实例需谨慎）
AOF（Append Only File）
以日志形式记录每个写命令，重启时重放 AOF 恢复数据。
刷盘策略：
always：每次写都刷盘，最安全，性能最差everysec：每秒刷盘，默认推荐，最多丢 1 秒数据no：由 OS 决定，性能最好，最不安全
AOF 重写：
- 文件膨胀时 fork 子进程重写，生成最小命令集合
- Redis 4.0+ 支持混合持久化：重写时前半段用 RDB 格式，后半段用 AOF 命令
对比表
| 维度 | RDB | AOF |
|---|---|---|
| 数据安全性 | 低（可能丢几分钟） | 高（最多丢 1 秒） |
| 文件大小 | 小 | 大 |
| 恢复速度 | 快 | 慢 |
| 性能影响 | 低（fork 瞬间） | 高（每次写都追加） |
| 适用场景 | 备份、从库同步 | 主库持久化 |
常见追问
| 追问 | 要点 |
|---|---|
| 混合持久化是什么？ | AOF 重写时先写 RDB 格式头部，再追加增量 AOF 命令，兼顾恢复速度和安全性 |
| fork 时内存不够怎么办？ | 开启 vm.overcommit_memory=1，或使用 no-appendfsync-on-rewrite=yes 减少 fork 期间冲突 |
| 如何选择？ | 允许分钟级丢失选 RDB；要求高可用选 AOF everysec；生产推荐混合持久化 |
面试回答模板（30 秒版）
延伸准备
- 能解释
BGSAVE的 COW（Copy-On-Write）机制 - 能说出 AOF 重写的触发条件：
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size - 能结合主从复制说明 RDB 在从库同步中的作用
