视频来源：B站 IT老齐
本文为视频学习笔记 + 扩展整理。
一、什么是"两地三中心"？
两地：同城 + 异地
三中心：生产中心 + 同城灾备中心 + 异地灾备中心
🌍 异地（>200km）
🏙️ 同城（≤200km）
同步复制
光纤专线
异步复制
广域网专线
🏢 生产中心
承担业务
RPO ≈ 0 / RTO ≈ 0
🏢 同城灾备中心
热备/双活
RPO ≈ 0 / RTO < 分钟级
🏢 异地灾备中心
冷备/温备
RPO 分钟~小时级 / RTO 小时级
一句话总结：同城保可用，异地保数据。
二、为什么需要两地三中心？
2.1 金融行业的特殊要求
金融系统（银行、证券、支付）对数据安全和业务连续性的要求极高：
- 钱不能丢：交易数据绝不能丢失（RPO ≈ 0）
- 业务不能停：银行转账、证券交易不能长时间中断（RTO 尽可能小）
- 监管要求：银保监会明确要求关键系统必须具备容灾能力
2.2 不同灾难等级的防范
| 灾难类型 | 举例 | 防范方案 |
|---|---|---|
| 硬件故障 | 服务器宕机、磁盘损坏 | 本地高可用（主从、集群） |
| 机房级故障 | 机房断电、网络中断、火灾 | 同城灾备 |
| 城市/区域级灾难 | 地震、洪水、大范围停电 | 异地灾备 |
单机房高可用防不了机房级故障，同城双中心防不了城市级灾难------所以需要"两地三中心"层层设防。
三、三个关键指标
| 指标 | 含义 | 举例 |
|---|---|---|
| RPO（Recovery Point Objective） | 能容忍丢失多少数据（以时间衡量） | RPO=0 表示一条数据都不能丢 |
| RTO（Recovery Time Objective） | 从故障到恢复业务需要多久 | RTO=30s 表示 30 秒内必须恢复 |
| 容灾半径 | 生产中心与灾备中心的地理距离 | 同城 ≤200km，异地 >200km |
金融监管分级要求：
| 等级 | 要求 | RTO | RPO | 适用系统 |
|---|---|---|---|---|
| 一级 | 两地三中心 | ≤ 1 分钟 | ≈ 0 | 核心交易系统 |
| 二级 | 两地两中心 | ≤ 5 分钟 | ≤ 分钟级 | 重要业务系统 |
| 三级 | 异地灾备 | ≤ 30 分钟 | ≤ 小时级 | 外围支撑系统 |
四、容灾等级：数据级 → 应用级 → 业务级
4.3 业务级容灾（双活）
双向实时同步
🏢 生产中心
🏢 灾备中心
同时承担业务流量
4.2 应用级容灾
实时数据同步
🏢 生产中心
📦 灾备中心
数据+应用已部署
不接流量
4.1 数据级容灾
定期备份/数据复制
🏢 生产中心
💾 灾备中心
仅有数据，无应用
4.1 数据级容灾
- 做法：定期备份或实时数据复制
- RTO：> 24 小时（需要手动部署应用、恢复数据、切换网络）
- 成本：最低
- 适用：非核心系统、冷数据备份
4.2 应用级容灾
- 做法：灾备中心部署相同应用环境，数据实时同步，但平时不对外服务
- RTO：< 12 小时（启动应用 + 切换流量）
- 成本：中等
- 适用：重要业务系统
4.3 业务级容灾（双活）
- 做法：两个中心同时承担业务流量，实时双向数据同步
- RTO：< 30 秒（切换对用户几乎无感知）
- 成本：最高
- 适用：核心交易系统
五、冷备、温备、热备、双活
| 模式 | 灾备中心状态 | 数据同步方式 | 切换速度 | 成本 |
|---|---|---|---|---|
| 冷备 | 关机/无应用，仅有数据备份 | 周期性备份 | 小时~天级 | 低 |
| 温备 | 有应用但不运行，数据准实时同步 | 异步复制 | 分钟~小时级 | 中 |
| 热备 | 应用已启动，随时可接管，不接流量 | 同步复制 | 秒~分钟级 | 较高 |
| 双活 | 与生产中心同时承担业务流量 | 双向实时同步 | 秒级，用户无感 | 最高 |
❄️ 冷备
关机/仅备份
RTO: 小时~天
🌤️ 温备
有应用不运行
RTO: 分钟~小时
🔥 热备
应用已启动
RTO: 秒~分钟
⚡ 双活
同时承担流量
RTO: 秒级
从左到右：成本递增，RTO 递减。
在"两地三中心"架构中的典型搭配：
- 同城灾备中心 ：热备 或 双活（同城网络延迟低，可以做同步复制）
- 异地灾备中心：冷备 或 温备（异地网络延迟高，只能做异步复制）
六、同城双活 vs 异地灾备
6.1 同城双活
50%
50%
同步复制
光纤专线 < 3ms
👥 用户流量
🏢 中心 A
生产中心
🏢 中心 B
同城灾备
核心特点：
- 两个中心同时对外提供服务，分担流量
- 通过高速光纤连接，数据同步复制，RPO ≈ 0
- 任一中心故障，另一个自动接管全部流量
- 距离通常 ≤ 200km（网络延迟 < 3ms）
关键挑战：
- 数据双向同步的冲突处理
- 分布式事务的一致性保证
- 流量切换的自动化（DNS、负载均衡、GSLB）
6.2 异地灾备
🏙️ 同城双活
同步
异步复制
广域网专线
延迟: 秒~分钟级
🏢 中心 A
🏢 中心 B
🏢 异地灾备中心
不承担业务
最后一道防线
核心特点：
- 距离 > 200km（甚至跨省），防范区域级灾难
- 数据异步复制，存在一定延迟（秒~分钟级）
- 平时不承担业务，仅做数据备份
- 真正的"最后一道防线"
关键挑战：
- 异步复制意味着可能丢少量数据（RPO > 0）
- 切换到异地中心需要较长时间（RTO 分钟~小时级）
- 灾备演练验证：冷备系统长期不用，真到切换时能不能起来？
七、各层的容灾方案
7.1 网络层
| 技术 | 说明 |
|---|---|
| GSLB（全局负载均衡） | 基于 DNS 智能解析，将用户流量分配到不同中心 |
| BGP Anycast | 同一 IP 在多个中心同时广播，就近接入 |
| VIP 漂移 | 同城双活中，通过 Keepalived / F5 实现虚拟 IP 秒级切换 |
7.2 应用层
| 技术 | 说明 |
|---|---|
| 无状态设计 | 应用服务器不保存会话状态，任意节点可接管 |
| 配置中心 | Nacos / Apollo，切换时统一变更配置 |
| 服务注册发现 | 多中心注册，故障时自动摘除不可用节点 |
7.3 数据层
| 方案 | 同步方式 | 适用场景 |
|---|---|---|
| MySQL 半同步复制 | 同步/半同步 | 同城灾备 |
| MySQL MGR | Paxos 强一致 | 同城双活 |
| Redis Sentinel / Cluster | 异步复制 | 缓存层容灾 |
| MQ 多副本（Kafka/RocketMQ） | 同步刷盘 + 多副本 | 消息层容灾 |
| 分布式数据库（TiDB/OceanBase） | Raft/Paxos | 天然支持多中心 |
7.4 存储层
| 技术 | 说明 |
|---|---|
| SAN 存储镜像 | 存储级别的数据同步（EMC SRDF、华为 HyperReplication） |
| 分布式存储 | Ceph / MinIO 多副本跨机房部署 |
八、方案总结
个人项目/开发环境
中小企业/非金融
金融核心/支付交易
超大规模/全球化
🤔 你的系统需要
什么级别的容灾？
单机房 + 定期备份
同城灾备（热备）
- 定期异地备份
🏦 两地三中心
同城双活 + 异地灾备
🌍 异地多活
三地五中心甚至更多
| 方案 | 成本 | RPO | RTO | 防范灾难级别 |
|---|---|---|---|---|
| 单机房高可用 | 低 | 秒级 | 秒级 | 硬件故障 |
| 同城灾备（热备） | 中 | ≈ 0 | 分钟级 | 机房级故障 |
| 同城双活 | 较高 | ≈ 0 | 秒级 | 机房级故障 |
| 两地三中心 | 高 | 同城 ≈ 0 / 异地分钟级 | 同城秒级 / 异地小时级 | 城市/区域级灾难 |
| 异地多活 | 最高 | ≈ 0 | 秒级 | 区域级灾难 |
核心原则：没有完美的容灾方案，只有成本和风险之间的权衡。RPO 和 RTO 越小，成本越高。根据业务的重要性和预算，选择合适的等级。
参考资料：