同城双活是什么
同城双活指同城两个机房或两个可用区同时承载流量，机房级故障时可以快速切换。延迟足够低才是真双活的前提，两个中心之间通常需要低延迟专线互联；数据层的写入策略则是这类架构里最难的部分。
基本信息
| 定义 | 同城两个中心同时对外服务，流量可双向调度 |
|---|---|
| 基础设施 | 两中心之间低延迟专线互联 |
| 流量调度 | 智能 DNS 权重或负载均衡主备与多活 |
| 数据层 | 单写多读热备，或业务层双写并处理冲突 |
| 容灾等级 | 高于单可用区，低于两地三中心 |
| 演练 | 切换必须定期演练，未演练的方案等于没有 |
各层次做法与风险
| 层次 | 常见做法 | 关键风险 |
|---|---|---|
| 流量入口 | 智能 DNS 权重、负载均衡 | DNS 缓存导致切换慢 |
| 应用层 | 无状态化、会话共享 | 会话不共享导致切换后掉线 |
| 数据层 | 主备或双写 | 双写冲突互相覆盖 |
| 中间件 | 集群跨中心部署 | 脑裂与数据一致性问题 |
| 演练 | 定期切换演练 | 未演练的方案不可信 |
流量调度切换示意
流量调度切换示意
正常：DNS 权重 50/50 → 双中心按容量承接
故障：探测发现 A 中心异常 → 权重切 0/100 → B 中心全量
# 切换耗时受 DNS 缓存影响，接线用短 TTL典型使用场景
- 核心业务要求机房级故障时仍能对外服务
- 两地三中心方案的中间形态，先做同城再扩异地
- 迁移期间新旧机房并行承载流量
- 大促前提升整体容量与可用性
数据库双写是同城双活最难的部分：多数团队实际落地为单写热备加秒级切换，而不是真正的双写，先想清楚再画架构图。
会话与本地缓存要提前改造：应用不做无状态或共享会话，切换后用户会集体掉线重新登录。
没有演练过的切换方案不可信：切换脚本、执行人、判断条件都要在真实演练中验证过一遍。