同城双活与异地多活：单元化入门
2026/8/24大约 3 分钟
亿级规模系统系列 · 阶段 6 · 高可用 · 第 37/49 篇 · 🚧 占位待学
上一篇：《中间件高可用盘点：MySQL、Redis、RocketMQ 与网关》
下一篇：《故障演练：把事故提前到演练室发生》
学习大纲：《QPS 过万与亿级消息系统设计学习总纲》
状态：待学习。 本文为占位文档：知识点清单、实验与验收标准已就绪，正文待按「先学习、先实验、再撰写」补全。
对应总纲单元：阶段 6 · 单元 6.4
一、本文要解决的问题
机器坏了有冗余，机房断了呢？同城双活用「近距离强同步」换 RPO≈0；异地多活面对物理距离的延迟，只能放弃强一致——按业务单元化，每个单元独立服务一部分用户。这一篇是架构的地理课：延迟决定了多活的形态。
二、知识点清单
- 演进阶梯：冷备（闲置）→ 热备（双份流量一份）→ 同城双活 → 异地多活，成本与 RTO 的阶梯
- 同城双活：距离近（2ms 级 RT），数据库可强同步（半同步 / MGR），两机房同时服务
- 异地多活：距离远（30ms+ RT），强同步不可行 → 按用户 / 业务维度单元化（A 机房服务北方用户，B 机房服务南方）
- 数据同步通道：DTS / otter / 自研 binlog 同步，冲突处理（以谁为准）
- 哪些业务能多活：可按用户分片（交易）能；全局强一致（库存扣减、账号唯一性）要特殊处理（全局服务 / 库存分段）
- 切流演练：故障时把一个单元的流量切到另一个单元，预案与验证
三、动手实验（学习时必须真跑）
- 纸面推演（画图）：把秒杀系统按「用户归属地」单元化，画双机房部署图、数据同步方向、全局服务清单
- 推演切换剧本：A 机房整体断电，B 机房如何接管——DNS 切流、数据追平校验、冲突处理
- 模拟实验：两个「机房」（两组 Docker），binlog 双向同步，制造一个写冲突观察冲突处理策略
四、验收标准（全部通过才进入下一篇）
五、写作提示（补正文时遵守）
- 开篇问题驱动；结构走「是什么 → 为什么 → 怎么做 → 背景知识」
- 所有代码、命令、输出必须先在本机跑通再写入，不得杜撰
- 版本口径以总纲环境清单为准（Spring Boot 3.x / MySQL 8.0 / Redis 8.x / RocketMQ 5.3.x / Kafka 4.3 / ShardingSphere 5.5.3）
- 涉及版本敏感结论时标注出处与时间
本篇完成后，把文首导航块的「🚧 占位待学」去掉，并在总纲处打卡。