这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
数据一致性
容灾系统最核心的取舍之一是数据一致性。跨地域复制天然有延迟，如果要求所有写入都在多个地域确认后才成功，延迟会升高；如果允许异步复制，就可能在故障时丢失一小段数据。
强一致与最终一致
强一致意味着写入成功后，所有关键副本都能看到结果。它适合账户余额、支付状态、库存扣减这类不能出错的数据。但跨地域强一致成本很高，可能降低可用性。
最终一致意味着数据会在一段时间后收敛。它适合评论、点赞、浏览记录、报表等场景。短时间不一致可以通过重试、补偿或延迟展示处理。
按业务拆分一致性
不要给整个系统套同一种一致性策略。更合理的是按数据类型拆分：
| 数据 | 一致性策略 |
|---|---|
| 支付流水 | 强一致或中心化写入 |
| 订单状态 | 主写 + 异步复制 + 对账补偿 |
| 库存 | 预分配、冻结或中心化扣减 |
| 用户资料 | 最终一致 |
| 操作日志 | 异步复制，允许延迟 |
这样可以把强一致成本集中在真正关键的数据上。
冲突处理
多活写入会遇到冲突。例如同一个用户在两个地域同时修改资料，或同一库存被两个地域同时扣减。常见策略有：
- 按用户或租户归属地路由，避免同一实体多地写。
- 使用版本号或时间戳检测冲突。
- 对可合并数据采用 CRDT 或累加合并。
- 对关键业务进入人工或补偿流程。
能避免冲突就不要制造冲突。很多系统所谓多活，实际应该先做分区单写。
对账与补偿
即使设计了同步，也要假设会出现差异。容灾系统需要对账任务：
- 比对主备订单数量和状态。
- 检查支付流水和订单状态是否一致。
- 发现消息重复或漏消费。
- 生成补偿任务或人工处理工单。
补偿能力决定了系统能否从不一致中恢复。没有对账的容灾系统，只能希望复制永远正确。
一致性与用户体验
有些不一致可以通过产品体验隐藏。例如切换后订单列表短暂延迟刷新，可以提示“数据恢复中”；但支付成功状态不能随意丢失。设计时要把一致性需求翻译成用户可接受的体验边界。
下一章我们会通过容灾演练验证这些假设是否真的成立。