容灾中的 RPO 和 RTO 是什么？如何设计容灾方案？
简化版
RPO 表示最多能丢多少数据，RTO 表示故障后多久恢复服务。容灾方案要根据业务等级确定 RPO/RTO，再选择备份、主备、同城双活、异地灾备或异地多活，核心是在成本、复杂度、数据一致性和恢复速度之间取舍。
详细版
两个指标的含义：
| 指标 | 关注点 | 例子 |
|---|---|---|
| RPO | 数据损失量 | 最多丢 5 分钟数据、最多丢 0 条交易 |
| RTO | 恢复时间 | 30 秒恢复、15 分钟恢复、4 小时恢复 |
常见容灾等级：
- 定期备份：成本低，RPO/RTO 都较大；
- 异地备份：能抗本地灾难，但恢复较慢；
- 主备容灾：备用环境可接管，RTO 较短；
- 同城双活：抗单机房故障，恢复快；
- 异地多活：抗地域级故障，但建设和治理成本最高。
设计容灾时要分业务等级。支付、订单、账户需要更小 RPO/RTO；后台报表、低频运营系统可以接受更长恢复时间。
完整版教学
一、RPO 关心数据，RTO 关心时间
容灾不是只问“有没有备份”，而是问故障发生后能损失多少数据、多久恢复服务。RPO 和 RTO 就是回答这两个问题的指标。
RPO 是 Recovery Point Objective，恢复点目标。它表示最多允许丢失多长时间窗口内的数据。比如 RPO = 5 分钟，意味着灾难发生后，系统最多可能回到 5 分钟前的数据状态。RPO = 0 则表示已确认的数据不允许丢失。
RTO 是 Recovery Time Objective，恢复时间目标。它表示从故障发生到服务恢复可用的目标时间。RTO = 30 分钟，意味着系统要在半小时内恢复核心服务。
二、不同业务的 RPO/RTO 不应该一样
账户余额、支付、订单状态通常对 RPO 要求很高，用户已支付的数据不能随便丢。登录、浏览、推荐、报表对数据损失和恢复时间的容忍度可能不同。
如果所有系统都按 RPO=0、RTO=分钟级建设，成本会非常高；如果所有系统都按普通备份处理，核心业务风险又太大。因此容灾设计首先要做业务分级：核心交易、重要业务、普通业务、内部工具分别设定目标。
这个分级能帮助团队把钱和工程精力花在最关键的地方。
三、备份只能解决一部分容灾问题
定期备份可以防误删、防勒索、防存储损坏，但它通常不能提供很小的 RPO/RTO。比如每天凌晨备份一次，下午数据库损坏，可能丢失当天数据；从备份恢复大库也可能花费数小时。
所以备份是底线，不是完整高可用。高等级业务还需要实时复制、主备环境、跨机房部署、自动切流和演练。备份恢复也必须定期验证，否则可能到真正需要时才发现备份不可用或恢复脚本失效。
四、容灾方案越高级，复杂度越高
主备容灾比备份恢复更快，但要维护备用环境、复制链路和切换流程。同城双活能抗单机房故障，但需要流量调度、数据同步和容量规划。异地多活能抗地域级灾难，但要处理跨地域延迟、数据冲突、用户归属和复杂演练。
每提升一个等级，成本和复杂度都会增加。容灾方案没有绝对最好，只有是否匹配业务目标。一个内部报表系统使用异地多活可能是浪费；一个支付系统只靠每日备份则风险过高。
五、容灾必须演练
很多团队有容灾文档，但没有演练。真正故障时，人员不知道谁拍板，脚本参数过期，备库复制延迟超标，DNS 切换不生效，监控没有覆盖恢复结果。这些都会让纸面方案失效。
容灾演练要验证完整链路：备份能否恢复，备用环境能否启动，数据能否追平，流量能否切过去，用户核心功能是否可用，切回流程是否安全。演练后要记录实际 RTO 和数据差异，用事实修正目标。
六、RPO/RTO 会反向决定技术方案
如果业务要求 RPO 接近 0，就不能只依赖异步备份或长延迟复制，需要同步、半同步、多数派提交或业务层确认机制。如果业务要求 RTO 分钟级，就不能只准备离线备份，还要有热备环境、自动化切流、预热缓存和演练过的恢复脚本。
反过来，如果一个内部报表系统允许 RPO 1 天、RTO 4 小时，就没必要上异地多活。每天备份、异地保存、人工恢复可能更符合成本收益。容灾设计应该由目标驱动，而不是看到别人用什么架构就照搬。
可以把方案和指标对应起来：定期备份适合较大 RPO/RTO；主从复制降低 RPO、缩短 RTO；同城双活缩短机房故障恢复时间；异地多活降低地域灾难影响，但成本最高。面试时说出“指标决定方案”，会比泛泛介绍灾备等级更专业。
七、容灾还要考虑恢复后的数据校正
灾难恢复不是服务重新启动就结束。恢复后要确认数据是否完整、消息是否重复或丢失、缓存是否需要重建、外部回调是否需要补偿、用户请求是否出现中间态。尤其是支付、订单、库存系统，恢复后必须对账。
例如主库故障切到异地备库，如果 RPO 不是 0，可能有部分已提交订单未同步。系统要通过消息、业务日志、支付渠道账单、客户端重试记录等恢复缺口。这个过程可能需要人工审核和补偿任务。
容灾演练也要验证恢复后的业务一致性，而不是只验证机器能启动。演练报告应该记录实际 RTO、实际数据差异、人工步骤、失败点和改进项。没有这些，RPO/RTO 只是写在方案里的数字。
八、常见误区与追问
这道题要紧扣「RPO/RTO 容灾指标」本身回答，不能把它混成泛泛的高可用套话。面试官通常不是只听定义，而是看你能不能把适用场景、关键流程、失败边界和工程取舍串起来，尤其要说明故障域、冗余、健康检查、切换流程、RPO/RTO 和演练结果。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | RPO 衡量最多丢多少数据，RTO 衡量多久恢复服务，二者决定备份、复制和切换方案 | 不要停在名词解释 |
| 流程机制 | 定义核心业务等级 -> 设定 RPO 和 RTO -> 选择同步或异步复制 -> 设计切换流程 -> 定期演练恢复 -> 复盘实际指标 | 要说清触发点、状态变化、确认点和失败兜底 |
| 工程取舍 | RPO=5 分钟表示最多接受丢 5 分钟数据，RTO=30 分钟表示故障后 30 分钟内要恢复服务 | 高可用不是永不故障，而是用冗余、隔离、自动切换和演练降低故障影响 |
RPO/RTO 容灾指标 面试拆解：
1. 定义核心业务等级
2. 设定 RPO 和 RTO
3. 选择同步或异步复制
4. 设计切换流程
5. 定期演练恢复
6. 复盘实际指标记忆钩子：先给结论，再拆流程，再讲数字例子和失败边界；回答「RPO/RTO 容灾指标」时要围绕题目问法收束，不要把相邻概念堆成一段没有重点的名词清单。
- 误区：RPO 和 RTO 是一回事。 RPO 是数据丢失窗口，RTO 是服务恢复时间。
- 误区：指标越小越好。 越小意味着更高成本、更复杂复制和更严格运维。
- 误区：有异地备份就能低 RTO。 备份恢复可能很慢，低 RTO 通常需要热备或双活。
- 追问：同步复制影响哪个指标？ 主要降低 RPO，但会增加写延迟。
- 追问：热备和冷备差别？ 热备资源常驻可快速切换，冷备成本低但恢复慢。
- 追问：如何证明达标？ 靠定期容灾演练记录实际恢复时间和数据差异。
九、加强记忆
RPO 问“最多丢多少数据”，RTO 问“多久恢复服务”。容灾方案要先按业务分级设目标，再选择备份、主备、双活或多活。没有定期恢复演练的容灾，只是写在文档里的愿望。