这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
同城双活与异地多活
同城双活
同城双活通常在同一城市的两个机房部署，网络延迟低，可以同时承载流量：
用户 -> 流量调度 -> 机房 A / 机房 B- 适合应对单机房故障。
- 不能应对城市级或区域级故障。
- 由于距离近，数据同步和一致性问题比异地多活简单。
异地多活
异地多活让多个地域同时提供服务。优势是抗地域故障，用户也可以就近访问。但复杂度最高：
- 数据跨地域复制延迟高。
- 用户写入可能发生冲突。
- 全局唯一 ID、库存、余额等强一致数据很难处理。
- 运维和发布都要考虑多地域状态。
多机房架构三种形态
主备架构
流量进主机房，备机房只同步数据实现简单数据冲突少切换要接管流量
局限：备用机房长期不承载真实流量，事故时可能暴露问题
同城双活
同一城市两机房同时承载流量网络延迟低可应对单机房故障一致性比异地简单
局限：不能应对城市级或区域级故障
异地多活
多个地域同时提供服务抗地域故障用户就近访问高可用
局限：复制延迟高、写入冲突、强一致数据难处理
关键认知：
异地多活通常需要业务拆分——把能本地闭环的业务留在本地域，把强一致核心能力集中或做特殊设计。
流量调度必须和数据状态一致：不能把用户切到一个没有其数据的机房。
异地多活需要业务拆分
把能本地闭环的业务留在本地域，把强一致核心能力集中或做特殊设计：
- 订单、支付等强一致：集中写或特殊设计。
- 评论、浏览等可最终一致：本地域闭环。
一句话
同城双活抗单机房故障、异地多活抗地域故障；异地多活复杂度最高，通常需要业务拆分——本地闭环业务留在本地域，强一致核心能力集中处理。
发现内容有问题？
告诉我们哪里需要改进。