RDB 与 AOF 的关系
RDB 保存数据结果，文件紧凑、加载快，但两次快照之间的写入会全部丢失；AOF 保存操作过程，丢失窗口由刷盘策略决定，代价是文件更大、恢复要重放命令。两者不是二选一：同时开启时 AOF 负责近实时恢复，RDB 负责冷备归档与快速重建基线，恢复能力上互为补充。选型的真正依据是业务能容忍多少数据丢失，以及磁盘与内存余量能否支撑。
基本信息
| 同时开启 | save 配快照节奏，appendonly yes 开 AOF，两者互不冲突 |
|---|---|
| 加载优先级 | 开启 AOF 且文件存在时优先加载 AOF，RDB 只作备份 |
| AOF 混合格式 | aof-use-rdb-preamble yes 让 AOF 基线部分用 RDB 格式，兼顾体积与加载速度 |
| 磁盘占用 | 双开时快照与 AOF 文件共存，容量规划要预留两份 |
| fork 开销 | 两种机制都要 fork，双开会更频繁地触发 fork |
典型使用场景
- 核心业务库：AOF everysec 保证秒级恢复能力，RDB 每天一份用于归档与跨机房留档
- 纯缓存业务：关闭 AOF 只留低频 RDB，把写盘开销降到最低，重建由回源完成
- 数据不大但要求高：两者都开，磁盘便宜而丢数据代价高，用冗余换确定性
- 批量计算与临时数据：不开持久化，重启后重新跑一遍任务更简单
- 迁移窗口：新实例先用 RDB 快速铺基线，再开 AOF 承接增量，缩短同步时间
双开配置与核对
双开配置与核对
redis-cli CONFIG SET save '3600 1 300 100' # 快照条件：1 小时 1 次或 5 分钟 100 次
redis-cli CONFIG SET appendonly yes # 开启 AOF
redis-cli CONFIG SET aof-use-rdb-preamble yes # AOF 基线用 RDB 格式
redis-cli CONFIG GET save appendonly # 复核当前值
redis-cli CONFIG REWRITE # 把运行时改动落回配置文件
redis-cli INFO persistence | grep -E 'aof_enabled|rdb_last_bgsave_status|aof_last_write_status'四维度对比
| 维度 | RDB | AOF |
|---|---|---|
| 文件体积 | 紧凑，通常显著更小 | 偏大，取决于命令历史与重写频率 |
| 恢复速度 | 直接加载，快 | 重放命令，慢 |
| 丢失窗口 | 取决于快照间隔，可能数分钟 | everysec 约 1 秒，always 接近零 |
| 运维复杂度 | 低，一个文件 | 涉及重写、文件管理与损坏修复 |
恢复演练必须针对真实加载来源：双开环境下重启优先加载 AOF，如果只演练 RDB 路径，会漏掉 AOF 文件损坏、截断、路径不可读等问题，真正出事时才发现恢复流程不成立。
双开会放大 fork 与磁盘 IO：快照与重写都会 fork 子进程并让内存短暂上涨，磁盘上同时存在快照与 AOF 文件也意味着更大的写入带宽。大实例开启前要评估内存余量与磁盘 IOPS，而不是只看功能是否可用。