Redis 4.0+ 同时存在 RDB 和 AOF 时只加载 AOF 文件，RDB 退化为冷备；需禁用 AOF 重写触发 RDB、手动定期备份至异地、明确恢复步骤并关闭 AOF 后启动。
Redis 生产环境同时开启 RDB 和 AOF 是可行的，但不是简单“开两个开关”就能获得双重保障——默认配置下 AOF 会覆盖 RDB 的恢复优先级，且混合使用时存在重写冲突、启动加载逻辑绕过 RDB、磁盘 I/O 放大等隐性风险。
Redis 启动时到底加载哪个文件？
Redis 4.0+ 在同时存在 dump.rdb 和 appendonly.aof 时，**只加载 AOF 文件**，无论 RDB 是否更新。这是硬编码逻辑，不受配置顺序或文件时间戳影响。
- AOF 文件存在 → 忽略 RDB，直接执行 AOF 重放
- AOF 文件损坏或不完整 → 启动失败（除非设置
aof-load-truncated yes） - 仅存在 RDB → 正常加载 RDB
- 两者都不存在 → 空实例启动
这意味着：RDB 在混合模式下退化为“冷备快照”，不参与主恢复流程；它的价值仅限于人工恢复、跨版本迁移或备份归档。
如何让 RDB 在故障后真正可用？
必须打破“依赖自动加载”的惯性思维，把 RDB 当作独立灾备资产来管理：
- 禁用 AOF 自动重写期间的 RDB 触发（关闭
auto-aof-rewrite-percentage或设为 0），避免 AOF 重写过程中意外触发bgrewriteaof带来的 fork 风险叠加 - 定期用
SAVE或BGSAVE手动生成 RDB，并将文件同步到异地存储（如 S3、NAS），路径需与dir配置分离，例如/backup/redis/dump_$(date +%F).rdb - 在部署脚本或运维手册中明确 RDB 恢复步骤：
cp /backup/redis/dump_2024-06-15.rdb /var/lib/redis/dump.rdb && chown redis:redis /var/lib/redis/dump.rdb，然后关闭 AOF（appendonly no）再启动
注意：不要依赖 CONFIG SET appendonly no 动态关闭 AOF——它不会删除已存在的 AOF 文件，下次重启仍会加载。
AOF + RDB 并存时最常踩的三个坑
这些不是文档里写明的警告，而是线上反复出现的真实故障点：
-
appendfsync everysec+no-appendfsync-on-rewrite yes组合下，AOF 重写期间若父进程发生阻塞（如内存 swap、CPU 抢占），可能造成 AOF 缓冲区堆积，重启时重放大量延迟命令，导致服务不可用超 10 分钟 - RDB 快照生成期间（尤其是大内存实例），fork 子进程会复制页表，若系统开启 THP（Transparent Huge Pages），可能触发内存分配卡顿，表现为
INFO persistence中rdb_bgsave_in_progress长时间为 1，且mem_fragmentation_ratio突增 - AOF 重写完成瞬间，新 AOF 文件被原子替换，但旧文件未立即释放（Linux 的 unlink 行为），若磁盘空间紧张，可能因残留文件占用导致后续重写失败，错误日志中出现
Can't open the append-only file: Permission denied（实际是 no space left）
真正起作用的容灾能力，来自可验证的 RDB 备份链路和清晰的 AOF 故障降级 SOP，而不是配置文件里多写的两行 save 和 appendonly yes。磁盘 IO、内核参数、备份校验、恢复演练——这些环节缺一不可，而它们全都不在 redis.conf 里。
