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