生产环境必须组合使用rdb和aof：rdb作冷备快照，aof负责实时写入；仅用aof有崩溃导致启动失败、重放慢、数据丢失风险；仅用rdb则丢失窗口大、fork开销高、无法增量修复。
Redis 生产环境不能只用 RDB 或只用 AOF —— 单一机制无法兼顾启动速度、数据丢失窗口和故障恢复可靠性。必须组合使用，且需明确各自角色：RDB 做冷备快照，AOF 负责实时写操作追加。
为什么不能只开 AOF？
AOF 文件会持续增长，重写（bgrewriteaof）虽能压缩，但存在两个硬伤：
- 重写期间若发生崩溃，可能生成不完整或校验失败的
appendonly.aof，导致 Redis 启动失败，报错Bad file format reading the append only file - AOF 重放耗时长，尤其当写流量大、命令多（如大量
lpush/hset）时，服务恢复时间远超 RDB 加载 - 默认
appendfsync everysec下，仍可能丢失最近 1 秒数据；设为always则吞吐暴跌，不适用于多数业务
为什么不能只开 RDB？
RDB 是定时快照，两次 save 或 bgsave 之间所有写入都不可恢复：
- 若配置为每 5 分钟触发一次
save 900 1，最坏情况丢失 5 分钟数据 -
save阻塞主线程，bgsave虽异步但 fork 开销大，内存翻倍风险在大实例（>10GB）中明显 - RDB 文件无命令级可读性，无法做增量修复或人工回滚某条误操作
appendonly yes + save 组合的关键配置项
启用双持久化后，RDB 不再是主恢复手段，而是 AOF 重写失败时的兜底，以及异地备份源。关键调整如下：
- 关闭自动 RDB 触发：注释掉所有
save行，避免干扰 AOF 主线；保留手动bgsave用于定期归档 - AOF 重写策略设为
auto-aof-rewrite-percentage 100且auto-aof-rewrite-min-size 64mb，防止小文件频繁重写 - 强制开启
aof-use-rdb-preamble yes：让 AOF 重写后以 RDB 格式开头，大幅提升加载速度（实测 2GB AOF 文件加载快 3–5 倍） - 日志同步选
appendfsync everysec—— 平衡性能与丢失窗口，别碰always
故障恢复时的实际流程与陷阱
Redis 启动时按固定顺序加载：先查 appendonly.aof，有则直接加载；无则 fallback 到 dump.rdb。但容易忽略三点：
- 若 AOF 文件损坏，Redis 默认拒绝启动；需手动执行
redis-check-aof --fix appendonly.aof修复，再删掉旧 RDB（否则可能误加载过期快照） - 运维脚本常漏掉 AOF 重写后的权限继承问题：
appendonly.aof由 Redis 进程创建，默认属主是redis用户，但重写后若父目录权限不对，下次重写会失败 - 从节点开启 AOF 时，
repl-backlog和 AOF 写入共用磁盘 IO，高写入下易触发IO timeout，建议将 AOF 文件路径挂载到独立 SSD 分区
真正难的是权衡：RDB 快但丢数据，AOF 全但慢且脆弱。生产里没有“开就完事”的配置，只有根据业务容忍度调参 —— 比如支付类服务必须关 AOF 的 everysec 改 always，并接受吞吐下降；而用户行为埋点可以接受 1 秒丢失，那就别碰 always。
