这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
RTO 与 RPO
容灾设计的第一步
容灾设计的第一步不是选技术，而是定义业务目标。没有 RTO、RPO 和业务分级，所有技术方案都会变成「越复杂越好」的堆砌。
RTO 与 RPO
| 指标 | 问题 | 示例 |
|---|---|---|
| RTO | 故障后多久恢复服务 | 支付系统 5 分钟内恢复 |
| RPO | 最多丢多少数据 | 订单数据最多丢 10 秒 |
指标背后的成本
- RTO 越短、RPO 越小，成本越高。
- RPO 接近 0 通常意味着同步复制或强一致方案，会带来延迟和可用性代价。
- 同步复制下，主库故障时甚至可能写不进去（可用性下降）。
目标驱动方案
目标不同，方案不同：
支付系统（RTO 5min / RPO 30s）
-> 热备 + 强同步复制
报表系统（RTO 2h / RPO 1d）
-> 冷备 + 每日备份恢复一句话
RTO 关注恢复时间，RPO 关注数据丢失窗口；RTO/RPO 越严格成本越高。先定义目标，才能判断方案是否足够。
发现内容有问题？
告诉我们哪里需要改进。