★ RDB 与 AOF 有什么区别？生产环境如何选型？
结论先行：RDB 是某一时刻的全量二进制快照，文件小、恢复快，但两次快照之间的数据可能丢失；AOF 以追加日志方式记录写命令，数据更完整但文件大、恢复慢。生产环境通常同时开启两者或直接使用 4.0+ 的混合持久化，兼顾恢复速度与数据安全。
一、两种持久化机制的原理
- RDB：父进程 fork 出子进程，子进程把内存数据写入临时文件后 rename 替换旧文件，主进程不阻塞写，只有 fork 瞬间可能有毫秒级停顿；
- AOF：写命令先追加到 AOF 缓冲区，再按刷盘策略写入 aof 文件，记录的是可重放的历史命令；
- AOF 重写（bgrewriteaof）：子进程基于当前内存生成最小命令集的新文件，解决 AOF 无限膨胀的问题；
- 混合持久化：AOF 重写后的文件头部为 RDB 快照、尾部追加增量命令，加载时先读快照再重放增量，兼顾体积与速度。
二、RDB 与 AOF 对比表
| 维度 | RDB | AOF |
|---|---|---|
| 文件格式 | 二进制快照 | 命令日志（混合模式含 RDB 头） |
| 恢复速度 | 快 | 慢，需要重放命令 |
| 数据丢失 | 可能丢两次快照间的数据 | 取决于刷盘策略，always 最多丢一条 |
| 文件体积 | 小 | 大，依赖重写控制 |
| 对主进程影响 | fork 瞬时阻塞 | 刷盘策略影响写延迟 |
| 适用场景 | 备份、冷备、快速恢复 | 数据完整性要求高的场景 |
三、关键配置命令
# AOF 刷盘三种策略
appendfsync always # 每条写命令都刷盘，最安全但最慢
appendfsync everysec # 每秒刷一次，默认方案，最多丢 1 秒数据
appendfsync no # 交给操作系统刷盘，最快但最不安全
# 开启混合持久化（Redis 4.0+）
aof-use-rdb-preamble yes
提示：RDB 的触发方式包括手动 bgsave 与配置的自动快照规则（如 save 900 1），自动快照本质也是 bgsave。
常见追问 / 记忆点
- 追问：实例重启后优先加载哪个？答：AOF，因为 AOF 数据更完整；只开 RDB 时加载 RDB。
- 追问：bgsave 会阻塞主进程吗？答：fork 瞬间可能阻塞毫秒级，之后子进程异步写盘，大实例 fork 耗时更长。
- 追问：always 与 everysec 怎么选？答：强一致场景选 always，一般业务选 everysec，两者吞吐差距可达数倍。
- 记忆点：RDB 管恢复速度，AOF 管数据完整性，混合持久化两头兼顾。