容灾备份
最坏的情况发生了：整个机房断电。
事件：
- 数据中心电力故障
- UPS 只能维持 30 分钟
- 发电机启动失败
- 整个机房离线
影响：
- 北京地域完全不可用
- 用户请求失败
- 数据可能丢失1. 多地域架构
之前架构：
北京（主） → 上海（从）
↓
广州（从）
问题：北京故障，无法写入
多活架构：
北京（主写入）
↓ ⇅
上海（主写入）
↓ ⇅
广州（主写入）
每个地域都可以：
- 处理读写请求
- 同步数据到其他地域
- 独立运行2. 数据同步策略
多活的前提是数据能在地域之间流动。同步策略要回答三件事：写在哪、复制用什么方式、延迟能被接受到什么程度。常见做法是主地域写入、异步复制到备地域，用户在本地地域读自己的数据以避开跨区延迟。要接受的是极端情况下备地域可能丢失最后几秒的写入，因此每条写入都必须带地域标记，后面的冲突处理才有依据。
2. 数据同步策略
- 步骤 1：确定写入归属：主地域写还是按用户分片写，并把归属写进数据记录
- 步骤 2：选择同步方式（异步复制或半同步），明确可接受的复制延迟上限
- 步骤 3：配置跨地域复制链路，并持续观测复制延迟和积压情况
- 步骤 4：为复制中断准备补偿机制，恢复后校验两端数据是否一致
关注点：同步方式、跨区延迟容忍度与写入来源的可追溯性。
3. 冲突解决策略
多地都能写，就必然会出现冲突。解决策略不能临时决定，必须事先写清：以谁为准（时间戳、版本号还是业务规则）、自动合并还是人工介入、冲突发生时用户看到什么。原则是冲突尽量少发生——通过写入归属划分把冲突挡在门外，实在躲不开的才进入冲突处理流程，并留下可追溯的处理记录。
3. 冲突解决策略
- 步骤 1：按写入归属和业务规则定义冲突判定条件，明确判定依据的字段
- 步骤 2：为每类冲突指定处理方式：自动合并、择一覆盖或转人工确认
- 步骤 3：在数据记录上保留版本号和写入来源，保证判定过程可追溯
- 步骤 4：演练一次真实冲突，验证处理结果符合预期且没有数据丢失
关注点：冲突判定规则、自动处理边界与人工介入路径。
4. DNS 故障转移
用户不会关心北京还是广州，他们只关心解析到的地址能不能用。DNS 故障转移就是把健康检查的结果接到解析层：探测到某地域整体不可用时，把域名解析切到健康地域，配合 TTL 控制回切节奏。DNS 有缓存、有传播延迟，所以它适合做地域级的粗粒度切换，秒级级的实例摘除还得靠更上层的负载均衡或应用层兜底。
4. DNS 故障转移
- 步骤 1：把各地域的健康探测结果接入 DNS 解析配置，定义摘除与恢复条件
- 步骤 2：设置合理的 TTL 缓存时间，平衡切换生效速度与解析压力
- 步骤 3：触发一次地域故障，验证解析切换到健康地域且用户请求恢复
- 步骤 4：规划原地域恢复后的回切流程，先灰度再全量切回并观察流量
关注点：健康探测接入、TTL 与切换生效时间以及回切策略。
5. 数据备份策略
同步解决的是「活下来」，备份解决的是「错了能回去」。两者的区别在于备份是周期性的、离线的、独立的，坏掉时不会被同步链路一起影响。策略要定三件事：备份哪些数据、保留多久、多久做一次恢复演练。只备份不演练等于没备份——真正需要时才会发现备份文件根本打不开。
5. 数据备份策略
- 步骤 1：确定备份范围：核心业务表、配置和密钥材料，并明确保留周期
- 步骤 2：执行周期性的全量加增量备份，备份文件异地保存并加密
- 步骤 3：校验备份完整性，定期做抽样恢复验证文件可用
- 步骤 4：定期演练从备份恢复整套服务，记录实际恢复耗时并修正方案
关注点：备份范围与保留周期、异地存放与恢复演练。
容灾方案是纸面方案还是真实能力，只有演练能说明。演练要模拟的是真实的灾难形态——整机房断电、地域完全离线，而不是只关掉一个进程。演练要能回答几个具体问题：切换要多久完成、这期间丢了多少数据、用户看到什么、恢复后怎么切回来。没有演练过的容灾方案，在真正断电时只会变成一份没人看懂的文档。
灾难演练
- 步骤 1：制定演练方案，设定故障场景、参与角色和 RTO/RPO 目标
- 步骤 2：在预发或隔离环境模拟地域级故障，执行完整的流量切换
- 步骤 3：记录切换耗时、数据丢失量和用户实际感知，输出演练报告
- 步骤 4：针对暴露的问题修正方案，并规划下一次演练与回切验证
关注点：演练真实性、RTO/RPO 指标与切回路径的验证。
真实上线还要注意
- 多活不是“哪里都能随便写”。 真正上线前，要先说清哪些数据可以多地写，哪些必须回主地写。
- 备份要真的恢复过。 只保存备份文件不够，至少要定期演练一次“从备份恢复服务”。
- 切换后也要能切回来。 灾难结束后怎么回到原来的地域，也要提前设计。
练习 1
如果北京机房完全离线，你会先恢复“所有功能”，还是先恢复“最关键的功能”？请给出你的恢复顺序。
解题思路：
真实故障里贪多只会拖慢恢复。这道题要先分清「关键路径」与「非关键功能」，按请求量和业务连续性排出恢复顺序，并且把回切当作独立的一步——切得回去不等于恢复完成。
详细步骤：
真实故障里不要追求一步恢复所有功能，先恢复关键路径更稳。
可以按这个顺序：
- 先恢复只读查询：天气查询、用户基础信息查询，让大多数请求先有结果。
- 再恢复关键写入：登录、API 调用记录、计费相关写入，保证业务能继续跑。
- 延后非关键功能：报表、后台复杂查询、历史数据导出可以先降级。
- 最后处理回切：北京恢复后，不要马上切回，要先校验数据同步和流量稳定性。
验收容灾方案时，不能只看“能不能切过去”，还要看 RTO、RPO、用户影响范围，以及切过去之后能不能安全切回来。
最终答案：
先恢复最关键的功能，顺序是：只读查询 → 关键写入（登录、调用记录、计费）→ 非关键功能降级 → 最后校验数据同步与流量稳定性后再回切。验收容灾方案不能只看「能不能切过去」，还要看 RTO、RPO 与用户影响面。
用户请求
GET https://api.kuaiyizhi.cn/v4/weather?city=上海智能 DNS（GeoDNS）
Nginx
Public API Gateway
Admin API
Admin Dashboard
MySQL
Redis 集群 + 哨兵
MySQL 多地域主从
消息队列
离线数仓
发现内容有问题？
告诉我们哪里需要改进。