这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
按业务拆分一致性与冲突处理
不要给整个系统套同一策略
更合理的是按数据类型拆分一致性策略：
一致性拆分
不要给整个系统套同一种一致性策略
| 数据 | 一致性策略 |
|---|---|
| 支付流水 | 强一致 · 强一致或中心化写入 |
| 订单状态 | 主写+补偿 · 主写 + 异步复制 + 对账补偿 |
| 库存 | 强一致 · 预分配、冻结或中心化扣减 |
| 用户资料 | 最终一致 · 最终一致 |
| 操作日志 | 最终一致 · 异步复制，允许延迟 |
要点：
把强一致成本集中在真正关键的数据上。跨地域强一致成本很高、可能降低可用性——
能避免冲突就不要制造冲突，很多系统所谓多活，实际应该先做分区单写。
冲突处理
多活写入会遇到冲突。例如：
- 同一个用户在两个地域同时修改资料。
- 同一库存被两个地域同时扣减。
常见策略有：
- 按用户或租户归属地路由，避免同一实体多地写。
- 使用版本号或时间戳检测冲突。
- 对可合并数据采用 CRDT 或累加合并。
- 对关键业务进入人工或补偿流程。
关键原则
能避免冲突就不要制造冲突。
很多系统所谓多活，实际应该先做分区单写：按用户或租户归属地路由，避免同一实体多地写。
一句话
一致性按数据拆分：支付流水强一致、订单主写+对账、用户资料最终一致。冲突能规避就规避——按归属地路由做分区单写，比解决冲突便宜得多。
发现内容有问题？
告诉我们哪里需要改进。