多区域 / 多 AZ 灾备

两个核心指标

指标	全称	含义
RTO	Recovery Time Objective	故障发生 → 业务恢复的目标时间
RPO	Recovery Point Objective	故障发生 → 数据最多丢失的时间长度

例：RTO = 15 分钟、RPO = 1 分钟 → "出了事 15 分钟内恢复，最多丢 1 分钟数据"。

这两个数不是技术决定，是业务决定。和老板 / 法务 / 客户合同对齐——再来选方案。

灾备的 4 种模式

按 RTO / RPO 从松到严：

1. 备份恢复（Backup & Restore）

RTO：小时级（要去对象存储拉数据 → 重建环境 → 恢复）
RPO：备份频率决定（每日备份 → 最多丢一天）
成本：最低
适合：内部工具 / 非核心服务

2. 冷备（Pilot Light）

RTO：分钟到小时级
RPO：取决于复制频率
成本：低（备区只跑核心数据库 + 最小服务）
适合：可以接受短暂停机的服务

3. 热备（Warm Standby）

RTO：分钟级
RPO：秒级（持续复制）
成本：中（备区有较完整服务但容量小）
适合：核心 SaaS

4. 多区双活（Multi-Region Active-Active）

RTO：近 0
RPO：近 0（取决于一致性策略）
成本：高（双倍 + 跨区流量费）
适合：金融 / 全球化 SaaS / 不可中断业务

Multi-AZ vs Multi-Region

很多人混淆这两个：

维度	Multi-AZ	Multi-Region
隔离单位	同区域内的多个数据中心	跨地理区域
故障类型	单 AZ 断电 / 网络故障	整个区域级灾难 / 法规要求数据本地化
跨网络延迟	低（同城）	高（跨城 / 跨国）
复杂度	低（云商默认能做）	高（数据一致性、DNS 切换、合规）
成本	几乎免费（资源同区）	资源 + 跨区流量 + 复杂运维

绝大多数业务先做好 Multi-AZ，Multi-Region 是少数业务的需求。Multi-AZ 解决的故障率显著更高（AZ 级故障比 Region 级常见得多）。

数据复制策略

策略	一致性	延迟	适合
同步复制	强（commit 必等所有副本）	高	金融 / 不允许丢数据
半同步（semi-sync）	强 - 一份	中	多数核心业务
异步复制	最终一致	低	日志 / 非关键数据

跨 Region 通常只能异步——光速决定了同步延迟无法接受。

DNS 切换：失败方案的常见做法

正常：app.wadely.com → A 记录 → us-east IP
故障：DNS 改 → 指向 backup region IP

注意：

TTL 要短（5 分钟以内），否则切换被全球 DNS 缓存拖慢
浏览器和某些客户端会忽略 TTL —— 实际生效慢于 TTL
全球 LB（AWS Global Accelerator / GCP Global Load Balancer / Cloudflare）能避免 DNS 缓存延迟

Cell-based Architecture

AWS 等大公司应对超大规模的设计：把用户分组到独立"细胞"，故障只影响一个细胞。

Cell 1: 100 万用户 → 独立 DB / app / cache
Cell 2: 100 万用户 → 独立 ...
...

某个 cell 挂了 → 影响 1 / N 用户

复杂度高，只在用户量极大时合算——不适合多数公司。

备份的"3-2-1"

所有公司都该有的最低实践：

至少 3 份副本
存储在 2 种不同介质
至少 1 份在异地

云上具体：

数据库自动备份（RDS / Cloud SQL / 阿里 RDS）
跨区复制到另一个 region（每日）
关键数据另存到对象存储归档层（Glacier / Archive Storage）

演练：备份不等于演练

"没演练过的备份等于没备份。"

定期做：

每季度从备份恢复一份到测试环境，验证完整性 + 用时
每半年做一次故障切换演练（手动 failover）
每年做一次完整 DR 演练（按下"假设 us-east 全挂"按钮）

不演练 → 真出事时发现备份过期 / 缺字段 / 不可用。

几条 design 原则

冗余从基础设施层开始：单点 LB / 单点 DB master = 等死
每个 region 自给自足：跨 region 调用 = 延迟 + 故障耦合
Failover 自动化：人来操作的失败转移 = 半夜没人 = 长 RTO
配置集中、可重建：region 没了，IaC 在能 30 分钟拉新区起来