这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
多机房架构
多机房架构决定了容灾系统的基本形态。不同形态的成本、复杂度和恢复能力差异很大。
主备架构
最常见的是主备：
用户流量 -> 主机房
备用机房同步数据，平时不接或少量接流量主备架构简单，业务只在主机房写入，数据冲突少。缺点是切换时需要接管流量，备用机房如果长期不承载真实流量，可能在事故时暴露配置、容量和数据问题。
同城双活
同城双活通常在同一城市的两个机房部署，网络延迟低，可以同时承载流量：
用户 -> 流量调度 -> 机房 A / 机房 B它适合应对单机房故障，但不能应对城市级或区域级故障。由于距离近，数据同步和一致性问题比异地多活简单。
异地多活
异地多活让多个地域同时提供服务。它的优势是抗地域故障，用户也可以就近访问。但复杂度最高：
- 数据跨地域复制延迟高。
- 用户写入可能发生冲突。
- 全局唯一 ID、库存、余额等强一致数据很难处理。
- 运维和发布都要考虑多地域状态。
异地多活通常需要业务拆分，把能本地闭环的业务留在本地域，把强一致核心能力集中或做特殊设计。
流量路由
多机房系统需要流量调度能力：
- DNS 解析：简单，但生效受 TTL 影响。
- 全局负载均衡：能按地域、健康状态和权重调度。
- 业务路由：按用户归属地、租户或数据分片路由。
容灾切换时，流量调度必须和数据状态一致。不能把用户切到一个没有其数据或数据落后的机房。
架构选择
选择多机房架构时，先问：
- 业务是否能接受短暂停机？
- 是否允许少量数据丢失？
- 写入是否强依赖全局一致性？
- 备用机房是否长期承载真实流量？
架构形态确定后，下一步就是数据同步。没有可靠数据，备用机房只是空壳。