RPO与RTO：容灾的两个关键指标

RPO和 RTO 都是容灾Disaster Recovery指标最直观的区分方式是它们在时间轴上一个向前看、一个向后看。RPO Recovery Point Objective恢复点目标→ 看故障之前能容忍丢多少数据RTO Recovery Time Objective恢复时间目标→ 看故障之后能容忍停多久一、核心对比RPORTO全称RecoveryPointObjectiveRecoveryTimeObjective中文恢复点目标恢复时间目标衡量对象数据丢失量以时间表示业务中断时长时间轴方向故障点往前故障点往后由什么决定备份 / 数据复制策略故障切换 / 恢复流程RPO/RTO 0 意味着一条数据都不能丢业务完全不中断典型追问「昨天 23:00 到故障的订单还在吗」「什么时候能重新下单」举个具体例子把两者拆开看数据库每天凌晨 2:00 全量备份14:00 主库磁盘损坏运维 16:00 用备份恢复完成并切流。RPO 实际 12 小时2:00 到 14:00 的数据全丢了RTO 实际 2 小时14:00 到 16:00 业务不可用这两个数字互相独立。RTO 很短但 RPO 很长是常见的糟糕状态——切换很快但切过去发现丢了半天数据业务上照样是灾难。二、RPO 由数据复制策略决定MySQL 视角RPO 本质上就是「数据副本落后主库多少」方案RPO代价每日全量备份小时1 天最低成本全量备份 binlog 归档PITR分钟级需要 binlog 完整归档异步复制MySQL 默认秒级但不确定——主库挂时未传出的 binlog 直接丢零性能损耗半同步复制semi-sync接近 0——至少一个从库确认收到 binlog 才向客户端返回每次写增加一个网络 RTT组复制 / MGR、Paxos/Raft 类如 TiDB、OceanBase0多数派确认架构复杂度高关键取舍RPO 0 必须靠同步复制而同步复制的写延迟直接受网络 RTT 约束。同机房 RTT 亚毫秒级代价可接受但跨城同步复制如北京—上海RTT 约 30ms会让每次写事务至少多花 30ms大量业务无法承受。这正是 CAP 在工程上的具体形态跨地域场景下RPO0 与低写延迟不可兼得。所以主流做法是同城双活同步RPO0 异地灾备异步RPO 秒级。三、RTO 由切换流程决定切换方式RTO人工发现 人工恢复 人工切流小时级有预案、人工触发脚本切换十分钟级MHA / Orchestrator 自动主从切换秒到分钟级云 RDS 自动主备切换通常 30 秒内多活架构流量直接调度到其他单元秒级注意 RTO不只包含数据库切换时间完整链路是RTO发现决策切换执行应用重连业务验证\text{RTO} \text{发现} \text{决策} \text{切换执行} \text{应用重连} \text{业务验证}RTO发现决策切换执行应用重连业务验证实践中「决策」环节经常是最大的黑洞——「要不要切谁批准」的拉群讨论可能比技术切换本身长十倍。所以高等级容灾必须把决策规则前置成自动化判定条件而不是靠临场判断。另外「应用重连」也常被低估连接池里的旧连接不会自动感知主库变更需要正确配置探活与快速失败。四、容灾等级对照等级方案RPORTO成本冷备定期备份存异地无运行环境小时天小时天极低温备异地有环境数据异步同步不承载流量分钟小时十分钟小时中热备异地实时同步随时可切不承载流量秒级分钟级高资源闲置同城双活双机房同时承载流量同步复制≈0秒级高异地多活多地域同时承载单元化拆分≈0本单元秒级极高「热备」的隐藏成本是资源常年闲置——这也是业界从「两地三中心」向「双活/多活」演进的主要动力既然要花钱建不如让它承担一半流量顺便持续验证它真的能用。五、一个必须区分的点RTO ≠ MTTR这两个概念极易混用但性质完全不同RTOMTTR性质目标 / 承诺事前约定实测统计值事后计算谁定的业务方与技术方协商由历史故障数据算出健康状态—MTTR 应当持续小于 RTO如果统计出的 MTTR 已经逼近或超过 RTO说明容灾能力不达标必须投入改造——而不是把 RTO 目标往上调。同样RTO 和上一轮的可用性也不是一回事可用性是全年累计统计值RTO 是单次故障的恢复时长上限。一个 RTO1 小时的系统如果全年只出一次故障可用性仍有 99.99%。六、三个高频误区6.1 备份成功 ≠ 能恢复这是最致命的。备份任务天天绿灯真要恢复时才发现备份文件损坏、恢复脚本失效、缺少解密密钥、恢复耗时远超预期。RPO / RTO 必须靠恢复演练验证不能靠文档声明。没演练过的容灾方案实际 RTO 应视为「未知」。6.2 只考虑数据库忘了其他有状态组件一次完整的容灾切换涉及数据库、消息队列未消费的消息在哪、缓存冷启动会不会击穿 DB、文件/对象存储、搜索索引、定时任务的执行状态。其中最容易被漏掉的是 MQ——如果订单已入库但 MQ 消息丢了下游的履约、通知、结算全部缺失数据一致性问题比丢数据更难修。6.3 同步复制防不住误删数据这一条极其重要也最反直觉DROP TABLE或DELETE FROM ... WHERE条件写错实时同步的副本会一模一样地删掉。RPO0 的同步复制在这个场景下完全失效——它忠实地复制了错误。主从复制防的是「物理故障」防不住「逻辑损坏」。应对手段是另一套PITRPoint-In-Time Recovery全量备份 binlog 重放到误操作发生前的精确时刻延迟从库delay replica故意让一个从库落后 1 小时CHANGE REPLICATION SOURCE TO SOURCE_DELAY3600给人留出反应窗口回收站 / 逻辑删除应用层不做物理删除从根上消除风险生产环境的完整容灾方案必须同时覆盖物理故障和逻辑损坏两条线。小结问题答案RPO 是什么RecoveryPointObjective可接受的数据丢失量看故障之前RTO 是什么RecoveryTimeObjective可接受的业务中断时长看故障之后各由什么决定RPO 由数据复制/备份策略决定RTO 由故障切换流程决定RPO0 的代价必须同步复制跨城场景下写延迟受 RTT 制约CAP 的工程形态RTO 的最大黑洞「要不要切、谁批准」的决策环节必须前置为自动判定条件RTO 和 MTTR 的区别RTO 是事前目标MTTR 是事后实测健康状态是MTTR RTO最容易踩的坑备份成功 ≠ 能恢复漏掉 MQ 等有状态组件同步复制防不住误删一句话记法RPO 问「丢了多少」RTO 问「停了多久」。两个数字必须由业务方给出丢一小时订单损失多少钱、停机一小时损失多少钱技术方据此选方案——反过来「技术上能做到多少就承诺多少」是本末倒置。