这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
开始 - 容灾概述
周五晚上，主机房网络抖动。监控先是出现少量接口超时，随后数据库连接池耗尽，订单服务开始大量失败。十分钟后，用户已经无法下单，客服群里不断有人问：“备用机房能不能切？”
这时团队才发现，所谓“备用机房”只是部署了几台机器：
- 数据库同步延迟不清楚。
- DNS 切换需要手工操作。
- 缓存没有预热。
- 消息队列没有跨机房消费方案。
- 没有人演练过完整切换流程。
容灾系统要解决的不是“有没有第二个机房”，而是当主系统不可用时，业务能否按预期恢复。
容灾目标
异地容灾关注两个核心指标：
- RTO（Recovery Time Objective）：系统从故障到恢复服务最多需要多久。
- RPO（Recovery Point Objective）：系统最多允许丢失多久的数据。
例如，订单创建系统可能要求 RTO 5 分钟、RPO 0 到 30 秒；报表系统可以接受 RTO 2 小时、RPO 1 天。不同业务不应该使用同一套容灾标准。
容灾不是高可用的替代品
高可用解决单点故障，容灾解决区域级故障。两者是不同层级：
| 层级 | 典型问题 |
|---|---|
| 进程级 | 服务崩溃、内存泄漏 |
| 机器级 | 单台服务器故障 |
| 集群级 | 数据库主节点故障 |
| 机房级 | 机房断网、供电故障 |
| 地域级 | 城市级网络或云厂商区域故障 |
容灾设计要先明确要防到哪一层，否则成本会失控。
课程主线
我们会先定义容灾目标，再选择多机房架构；随后处理最难的数据同步和一致性；再设计故障转移和回切流程；最后通过容灾演练验证系统真的可用。
一个成熟的容灾系统应该能回答：故障怎么发现、谁来决策、怎么切流、数据如何保证、服务如何降级、恢复后如何复盘。