Redis RDB 和 AOF 选择 怎样处理

Redis 的持久化选择，核心不是“RDB 和 AOF 哪个绝对更好”，而是先确定业务能接受丢失多久的数据。只要数据可以从数据库重建、丢失最近一段缓存也能接受，RDB 快照通常更轻；如果 Redis 承担不能轻易重放的写入，AOF 更适合；两者同时打开，则用 RDB 的恢复起点加 AOF 的增量记录换取更完整的恢复能力。

官方地址：https://redis.io/docs/latest/

简单决策：可重建的缓存优先考虑 RDB；数据丢失窗口要求小于一个快照周期时考虑 AOF；既要备份文件又要缩短恢复窗口时采用 RDB+AOF，并把 fsync 策略和恢复演练一起纳入方案。

先把 RDB 和 AOF 的职责分开

RDB 是某个时刻的数据集快照，文件紧凑，适合备份、搬迁和快速加载，但两次快照之间的写入可能没有落盘。AOF 记录改变数据集的写命令，重启时重新执行这些记录；它的可靠程度由 appendfsync 决定。Redis 7 以后 AOF 采用多部分文件和清单管理，不能简单假设只有一个传统的 appendonly.aof 文件。

两者都不是高可用的替代品。主从复制、哨兵或集群解决的是服务可用性与故障切换；持久化解决的是实例重启后能恢复多少数据。生产环境还要明确备份文件保存位置、磁盘空间和恢复演练责任。

按数据丢失窗口和恢复成本选择

可以先写出四个约束：最多能丢多少时间的数据、重启后希望多久恢复、磁盘是否紧张、写入延迟能增加多少。RDB 适合“丢失最近几分钟仍可接受”的缓存或派生数据；AOF 的 everysec 通常把风险压到约一秒量级，但不是零丢失承诺；always 更偏向耐久性，代价是每批写入都要等待同步。no 把刷新交给操作系统，风险与刷新时机更难控制。

最小配置与切换检查清单

下面是示意配置，数值要按业务写入量、磁盘和恢复目标调整。不要直接把示例覆盖到生产实例。

# RDB：按数据变化和时间触发快照，适合可接受窗口的场景
save 900 1
save 300 10

# AOF：每秒同步，通常在可靠性与写入延迟之间取平衡
appendonly yes
appendfsync everysec

# 混合持久化：AOF 重写时使用 RDB 形式的基线，减少重放长度
aof-use-rdb-preamble yes

如果实例原先只有 RDB，切换到 AOF 时应在运行中的实例通过受控配置变更完成转换，再确认 AOF 重写成功并持久化配置；不要只改文件后直接重启。切换前先备份现有 dump.rdb，并预留足够磁盘空间。

上线前用 INFO persistence 验证目标

配置写完不等于数据已经可恢复。至少观察 AOF 是否启用、最近一次重写是否成功、重写是否正在进行，并把故障重启或备份恢复演练做成固定检查。

# 查看持久化状态；输出是检查入口，不代表已经完成恢复演练
redis-cli INFO persistence

# 只筛选关键字段，便于记录重写和同步状态
redis-cli INFO persistence | grep -E 'aof_enabled|aof_last_bgrewrite_status|aof_rewrite_in_progress|rdb_last_bgsave_status'

如果只需要缓存，选择 RDB 也要确认上游重建路径不会把恢复压力集中到数据库；如果选择 AOF，要关注重写期间的磁盘峰值和 fork 造成的资源抖动。最终结论应来自一次可重复的恢复演练，而不是“配置文件看起来正确”。

常见问题

RDB 和 AOF 能同时开启吗？

可以。组合方案常用于既要定期快照，又要缩小增量丢失窗口的场景；但它会增加磁盘、重写和运维复杂度，不能替代备份保留与恢复测试。

appendfsync everysec 是完全不丢数据吗？

不是。它表示 Redis 通常每秒同步一次 AOF，故障时仍可能丢失最近一次同步前后的写入。能否接受这段窗口，应由业务数据价值和恢复流程决定。