DISASTER RECOVERY CONSOLE · REDIS
RPO / RTO 决策实验室
先说清楚“最多能丢多少、多久必须恢复”，再谈 RDB 和 AOF。这里估算的是故障边界，不是假装精确的生产承诺。
ESTIMATE / 估算模式
当前建议
AOF everysec
1 秒级 RPO 与写入性能折中
潜在丢失记录
5,000
按约 1 秒窗口估算
粗略恢复时长
约 11 分 41 秒
含文件载入与日志重放系数
保住 1 秒边界，比追求“零丢失”更现实匹配
AOF everysec 通常把最近约 1 秒写入留在风险窗口里。对数据库是真相源的业务，它能让 Redis 更快回到可服务状态，同时不把 Redis 误当成最终账本。
故障前的未落盘时间尺
条带越长，可能回退得越远RDB 的窗口取决于快照间隔；此处用常见的 5 分钟快照估算。真实结果还会受写盘、重写、硬件和故障类型影响。
复制不是备份。误删、错误写入和逻辑污染会被同步到副本。副本解决可用性，独立备份与恢复演练才解决可恢复性。
五种方案，同一组故障参数
“符合”只比较当前 RPO 容忍度；最终决策仍要压测与演练。
| 方案 | 估算 RPO | 潜在丢失 | 估算 RTO | 写入代价 / 边界 | 当前判断 |
|---|
把两个目标拆开，讨论才不会跑偏
RPO 回答“故障后最多允许回退多远”。AOF everysec 的风险窗口常按约 1 秒理解；RDB 则可能退回上一次快照。
RTO 回答“多久恢复服务”。文件越大、载入越慢、AOF 需要重放的命令越多，恢复时间越长。持久化更勤快，并不自动意味着恢复更快。
这组数是容量预演，不是 SLA
实验室用线性模型把选择的代价摊开。生产还要把实例启动、AOF 重写状态、校验、DNS 或流量切换、缓存预热和人工确认算进恢复链路。
潜在丢失记录 ≈ 每秒写入量 × RPO 窗口
粗略恢复时长 ≈ 数据量 ÷ 有效恢复吞吐 + 启动开销
粗略恢复时长 ≈ 数据量 ÷ 有效恢复吞吐 + 启动开销