大厂都会涉及到两地三中心架构，下面我详解两地三中心架构@mikechen
什么是“两地三中心”？
两地：两个城市（例如：北京、上海）。
三中心：指三个数据中心/机房：生产中心（主中心，日常承载全部或大部分业务流量）。
同城容灾中心（同城灾备中心，距离生产中心通常几公里到几十公里）。
异地灾备中心（远程备份中心，位于另一个城市）。
城市A： 主中心（Active） 同城灾备（Standby） 城市B： 异地灾备（Disaster Recovery）
简单来说就是一个“同城双活 + 异地灾备”的组合架构。
两地三中心架构
两地三中心架构 的核心目标是：在城市级故障（如停电、断网、火灾）时，业务仍能快速恢复。
同时尽量保证数据不丢失（RPO 接近 0）、恢复时间较短（RTO 较短）。
用户请求（DNS / GSLB）
↓
┌─────────────────────┐
│ 城市A（主中心） │
│ SLB → Nginx → 应用 │
│ ↓ │
│ 主数据库 │
└─────────────────────┘
↓（同步复制）
┌─────────────────────┐
│ 城市A（同城备） │
│ 从数据库 │
└─────────────────────┘
↓（异步复制）
┌─────────────────────┐
│ 城市B（异地中心） │
│ 灾备数据库 │
└─────────────────────┘
本质：当一个城市整体不可用时，系统仍然能继续运行。
先实现同城双活
同城两个机房部署完整应用集群，网络专线低延迟连通。
数据库同城内采用同步复制，保证数据一致，例如：
MySQL：MGR、PXC、或主从 + 半同步；
云数据库：PolarDB 两地三中心副本、OceanBase 等多副本架构。
业务流量按用户分区（如按用户 ID、区域分片）绑定到固定机房，尽量同城闭环，避免跨机房写。
这一步完成后，就达到了“同城双活”级别，可防御单机房故障。
增加异地灾备中心
在异地城市部署一个灾备机房，应用可先以“冷备”或“热备”模式运行：
冷备：平时不对外服务，仅同步数据；
热备：可以跑读流量或部分只读服务，但写流量仍由主中心承担。
数据从同城主中心异步或延迟复制到异地：
保证 RPO 很小（如几十秒级别），但避免阻塞写入。
配置灾备中心监控与演练流程，确保切换时可快速拉起业务。
建设统一容灾与演练流程
制定容灾预案：
单机房故障 → 自动切到同城另一机房；
同城整体故障 → 人工或半自动切换到异地灾备中心。
定期做“机房级切换演练”：
模拟停电、断网、数据库故障，验证 RTO 与 RPO 是否达标。