什么是"灾备"，两地三中心是什么意思

目标

灾备（DR，Disaster Recovery）：在发生区域性灾难（地震、洪水、断电、大规模故障）时，保证业务能够继续或被恢复。

两个关键指标：

RTO：多久能恢复服务；
RPO：最多丢失多少数据。

常见的灾备架构

一、备份恢复（最基础）

在异地保存备份，灾难发生后重建环境并恢复数据。

RTO：数小时到数天；
RPO：取决于备份频率（数小时到一天）；
成本：最低。

二、冷备（Cold Standby）

异地有一套环境，但不运行（或只运行基础服务）。灾难发生后启动并恢复数据。

RTO：数小时；
成本：中等（只需存储和资源预留）。

三、温备（Warm Standby）

异地环境部分运行（如应用已部署、数据库在同步），灾难后需要少量操作即可切换。

RTO：数十分钟到数小时。

四、热备（Hot Standby / Active-Standby）

异地环境完全运行，数据实时或准实时同步。灾难时切换流量。

RTO：分钟级；
RPO：秒级到分钟级；
成本：高（需要双倍资源）。

五、双活 / 多活（Active-Active）

多个站点同时对外提供服务，流量在它们之间分配。

一个站点故障时，流量自动切换到其他站点；
资源利用率最高（不是闲置的备份）；
RTO 接近 0。

代价：

数据一致性极难处理（跨站点的分布式事务、冲突解决）；
应用架构需要专门设计（无状态、数据分片或全局一致性方案）；
运维复杂度最高。

多活通常从"读多活 + 写单点"或"按用户分片的多活"起步，而非全局写多活。

"两地三中心"

中国金融等行业常用的灾备架构：

两地：两个地理上相距较远的城市（避免同一区域性灾难）；
三中心：
- 生产中心（主）；
- 同城灾备中心：同一个城市（或邻近）的第二个中心，数据同步复制（RPO≈0），可快速切换；
- 异地灾备中心：位于另一个城市，异步复制，用于应对区域性灾难。

设计逻辑：

同城灾备应对机房级故障（火灾、停电、设备故障）——切换快，数据不丢；
异地灾备应对城市级灾难（地震、洪水）——距离远，但可能有少量数据丢失（异步复制）。

这体现了风险分层 + 成本权衡的思想。

数据复制的关键取舍

同步复制：

主库写入必须等备库确认；
RPO = 0（数据不丢）；
代价：写入延迟增加（受网络往返影响），且备库故障会阻塞主库写入（可用性下降）。

异步复制：

主库写入立即返回，数据稍后同步；
RPO > 0（可能有数据丢失窗口）；
代价：故障时可能丢失最后一批数据；
优势：性能影响小，距离可以很远。

半同步：折中（等至少一个备库确认，但可退化为异步）。

选择取决于：业务的 RPO 要求 + 网络条件（延迟和带宽）。

一个常被忽略的问题：灾备演练

灾备系统如果从未演练过，就不可信。

常见问题：

切换脚本从未实际运行过，有 bug；
依赖关系不完整（如漏了 DNS、证书、配置中心、消息队列）；
容量不足（灾备中心的资源规格低于生产，切换后撑不住）；
人员不熟悉流程，慌乱中出错。

实践：

定期演练（如每年 1–2 次）；
演练要真正切换流量（而非只是单机测试）；
记录和改进。

另一个常被忽略的：依赖的完整性

灾备环境不只是应用和数据库——还有：

DNS / 负载均衡；
身份认证系统；
配置中心；
消息队列、缓存；
第三方服务的连通性和配额；
监控和告警系统本身。

监控系统放在被监控的区域内，是一个典型的设计错误——区域故障时你既丢了服务，也丢了观测能力。