Redis RDB 和 AOF 怎么按可接受数据丢失量选择

Redis 选 RDB 还是 AOF，先问业务能接受丢失几秒还是几分钟的数据。能接受几分钟、又重视备份体积和重启速度，可以以 RDB 为主；不能接受快照间隔内的写入丢失，通常选 AOF 并把 appendfsync 设为 everysec；订单、账户这类重要数据还要把 RDB 备份与 AOF 组合起来。关键不是“哪种持久化更安全”，而是把丢失窗口、写入开销和恢复目标同时写清楚。

先把可接受丢失量换成配置目标

先写一张业务表，而不是先改 redis.conf。例如，临时缓存可以接受丢失，排行榜或会话可能接受几十秒，订单状态则往往只能接受很小的窗口。这里的“可接受”指 Redis 实例异常、机器掉电或进程被强制终止后的恢复差额，不等同于主从切换或跨机房灾备承诺。

表格里的时间是决策起点，不是保证值。磁盘故障、文件损坏、错误删除和机房级事故还需要独立备份与恢复方案。

RDB、AOF 和双持久化怎么取舍

RDB 把某个时间点的数据写成单个紧凑文件，适合定期归档、跨机器传输和大数据集快速重启。它的代价是快照之间的写入没有单独记录，异常停止时可能回到上一个快照点；大数据集频繁快照还会带来 fork 和写时复制压力。

AOF 追加记录改变数据集的命令，重启时重放日志。它更贴近“最近写入”，但文件通常更大，需要后台重写，而且 fsync 策略会直接影响延迟和耐久性。Redis 7 以后 AOF 使用多部分文件和 manifest，备份时不能只凭旧版本的单文件经验复制。

如果同时开启 RDB 和 AOF，Redis 重启时会使用更完整的 AOF 来重建数据；RDB 仍然承担紧凑备份和快速回滚的价值。因此，对“数据重要但仍需可操作恢复”的实例，RDB+AOF 往往比单押一种方式更稳妥。

把 fsync、恢复和备份写进落地流程

一个偏稳妥的起点可以是：

# AOF 记录写入，everysec 在耐久性和吞吐之间取折中
appendonly yes
appendfsync everysec

# 保留时间点快照，具体频率按数据量和恢复目标调整
save 60 1000
save 300 10

# AOF 过大时允许后台重写，阈值需结合磁盘余量观察
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

appendfsync always 会在追加后频繁刷盘，适合极小丢失窗口但可能显著增加写入成本；no 把刷盘交给操作系统，速度更快但风险不可控。配置改完后，用 INFO persistence 查看 aof_enabled、aof_rewrite_in_progress 和最近一次重写状态，再做一次受控重启，确认键数量和关键业务样本都能恢复。

备份也要单独验收：RDB 文件生成后可复制到异地存储；只使用 AOF 时，Redis 7+ 应按 appenddirname 目录及 manifest 处理，并避开正在进行的重写。没有恢复演练的“备份成功”，只能说明文件被复制过，不能说明灾难时可用。

常见问题

RDB 和 AOF 能不能只选一个？

可以。可接受几分钟丢失且偏重备份时可选 RDB；更重视最近写入时选 AOF。重要数据通常保留 RDB 备份，再用 AOF 缩小恢复窗口。

everysec 是不是绝对只丢一秒？

不是绝对 SLA。它表示 Redis 通常每秒刷盘，故障时可能丢失最近约一秒写入，实际还受内核、磁盘和故障类型影响。

开启 AOF 后还需要 RDB 吗？

多数重要实例仍建议保留。RDB 文件更适合历史备份和异地传输，也能作为 AOF 异常时的恢复兜底。

只做主从复制能替代持久化吗？

不能。复制解决的是副本可用性，不能替代独立备份；误删、错误写入或同一故障域损坏可能同时影响主从。