这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
容灾备份
场景
最坏的情况发生了：整个机房断电。
事件：
- 数据中心电力故障
- UPS 只能维持 30 分钟
- 发电机启动失败
- 整个机房离线
影响：
- 北京地域完全不可用
- 用户请求失败
- 数据可能丢失解决方案：多活容灾
1. 多地域架构
之前架构：
北京（主） → 上海（从）
↓
广州（从）
问题：北京故障，无法写入
多活架构：
北京（主写入）
↓ ⇅
上海（主写入）
↓ ⇅
广州（主写入）
每个地域都可以：
- 处理读写请求
- 同步数据到其他地域
- 独立运行2. 数据同步策略
设计流程
2. 数据同步策略
- 步骤 1：同步跨节点数据并检查延迟
- 步骤 2：准备地域拓扑、健康状态、路由规则和复制进度
- 步骤 3：同步跨节点数据并检查延迟
- 步骤 4：校验延迟、一致性和故障切换结果
关注点：路由准确性、跨区延迟、一致性和故障切换。
3. 冲突解决策略
设计流程
3. 冲突解决策略
- 步骤 1：触发隔离、熔断、降级或恢复动作
- 步骤 2：触发隔离、熔断、降级或恢复动作
- 步骤 3：确认恢复状态、告警收敛和用户影响范围
- 步骤 4：校验身份、密钥或权限
关注点：故障隔离、恢复路径、用户影响和告警收敛。
4. DNS 故障转移
设计流程
4. DNS 故障转移
- 步骤 1：检测故障并完成切换恢复
- 步骤 2：准备健康指标、阈值、兜底方案和恢复步骤
- 步骤 3：检查健康状态并触发告警
- 步骤 4：确认恢复状态、告警收敛和用户影响范围
关注点：故障隔离、恢复路径、用户影响和告警收敛。
5. 数据备份策略
设计流程
5. 数据备份策略
- 步骤 1：备份关键数据并校验可恢复性
- 步骤 2：备份关键数据并校验可恢复性
- 步骤 3：备份关键数据并校验可恢复性
- 步骤 4：备份关键数据并校验可恢复性
关注点：故障隔离、恢复路径、用户影响和告警收敛。
灾难演练
设计流程
灾难演练
- 步骤 1：检测故障并完成切换恢复
- 步骤 2：采集健康状态并触发告警
- 步骤 3：识别故障信号、受影响服务和降级边界
- 步骤 4：根据失败率、超时和依赖状态选择保护策略
关注点：故障隔离、恢复路径、用户影响和告警收敛。
真实上线还要注意
- 多活不是“哪里都能随便写”。 真正上线前，要先说清哪些数据可以多地写，哪些必须回主地写。
- 备份要真的恢复过。 只保存备份文件不够，至少要定期演练一次“从备份恢复服务”。
- 切换后也要能切回来。 灾难结束后怎么回到原来的地域，也要提前设计。
练习
练习 1
如果北京机房完全离线，你会先恢复“所有功能”，还是先恢复“最关键的功能”？请给出你的恢复顺序。
参考答案 (3 个标签)
容灾 恢复顺序 故障演练
真实故障里不要追求一步恢复所有功能，先恢复关键路径更稳。
可以按这个顺序：
- 先恢复只读查询：天气查询、用户基础信息查询，让大多数请求先有结果。
- 再恢复关键写入：登录、API 调用记录、计费相关写入，保证业务能继续跑。
- 延后非关键功能：报表、后台复杂查询、历史数据导出可以先降级。
- 最后处理回切：北京恢复后，不要马上切回，要先校验数据同步和流量稳定性。
验收容灾方案时，不能只看“能不能切过去”，还要看 RTO、RPO、用户影响范围，以及切过去之后能不能安全切回来。