Redis如何选择RDB还是AOF模式？

必须同时启用RDB和AOF，因RDB存在定时快照导致的数据丢失窗口（如默认15分钟），且无法应对误删操作；AOF则易损坏、恢复慢、体积膨胀，单独使用风险高；混合模式通过AOF文件开头嵌入RDB快照并追加增量命令，兼顾恢复速度与数据完整性。

必须同时启用 RDB 和 AOF，不能只选其一。 单独用 RDB 会丢数据，单独用 AOF 容易损坏且恢复慢，最新推荐和生产环境实际落地的方案是两者共存、分工明确。

为什么不能只开 RDB？

RDB 是定时快照，两次快照之间的写入全部丢失。比如默认配置 save 900 1（15 分钟内至少 1 次修改），意味着宕机可能丢失最多 15 分钟数据。即使调高频率（如 save 60 10000），仍存在窗口期，且频繁 fork + 写大文件会拖慢主进程、增加内存压力。

1. 触发条件靠写操作次数和时间，不是实时的
2. 快照过程虽异步（bgsave），但 fork 子进程在内存大时可能卡顿甚至失败
3. 无法应对单次误删（DEL、FLUSHALL）这类操作——快照里也存了这个“已删”状态

为什么不能只开 AOF？

AOF 文件本质是命令日志，长期运行后体积膨胀严重，重写（bgrewriteaof）本身也耗 CPU 和 I/O；更关键的是，它容易因磁盘满、断电、写中断等原因损坏，导致整个文件不可读。

1. appendfsync always 安全但性能暴跌，基本不用
2. appendfsync everysec 是折中选择，但仍有最多 1 秒丢失风险
3. 损坏后需用 redis-check-aof 修复，修复失败就得丢数据或回退到 RDB
4. 重启加载时要逐条重放命令，1GB AOF 文件可能要几分钟

怎么配 RDB + AOF 混合模式？

Redis 4.0+ 支持混合持久化，即 AOF 文件开头是 RDB 格式快照，后面是增量命令——既压缩体积，又加速启动。但注意：混合模式不替代双备份逻辑，只是优化 AOF 文件结构。

1. 开启 AOF：appendonly yes，并设 appendfsync everysec
2. 保留 RDB 触发规则（如 save 300 10），用于生成冷备快照
3. 启用混合模式：aof-use-rdb-preamble yes
4. 确保 dir 目录有足够空间，appendfilename 和 dbfilename 不冲突

启动时 Redis 优先加载 AOF；若 AOF 不存在或损坏，自动 fallback 到最新 dump.rdb；两者都坏才真正丢数据。

容易被忽略的细节

很多人以为开了 AOF 就万事大吉，却忘了检查 stop-writes-on-bgsave-error 和 stop-writes-on-bgrewriteaof-error 是否为 yes——一旦后台持久化失败（比如磁盘满），Redis 会直接拒绝写入，业务立刻报错。这不是 bug，是保护机制，但必须配合监控告警，否则问题会静默积累。