概念卡片：高可用架构（双活与异地多活）

一句话机制：多活架构解决「机房级故障」的容灾——从冷备（备份不接流量）→ 热备（待机随时接管）→ 双活（两机房同时服务）→ 多活（多机房按规则分流），核心难点不是「多部署几套」，而是数据同步和流量调度。

容灾等级演进

等级	机制	特点
冷备	全量备份，平时不接流量	成本低，恢复慢（手动）
热备	系统运行但不承担流量	断电即接管，资源半闲置
双活	两机房同时服务，互为备份	任一机房挂，另一立即顶上
多活	多机房分流，双活升级版	就近访问 + 容量扩展

同城双活 vs 异地多活

维度	同城双活	异地多活
延迟	专线直连，延迟小	跨城，延迟高
容灾能力	机房级	城市级（防自然灾害）
复杂度	低（入门款）	高（复杂度质变）
流量分配	主备 / 负载分担(7:3) / 按业务拆分	单元化 + 智能调度

异地多活的核心：单元化

把系统按维度（如用户 ID）切成多个相对独立的单元，每个单元有自己的应用 + 数据，用户固定路由到自己的单元——像「大食堂分成小食堂」，一个单元出问题不影响其他单元。

数据同步三类方案

层级	方案
数据库级	MySQL 主从（有延迟）/ Group Replication（多主）/ 分库分表+中间件
消息队列级	Kafka 异步同步 / RocketMQ 多活
应用级	双写 / 异步补偿 / 事件驱动

不变量（必须成立的约束）

• 多活的一致性是最终一致，不要追求强一致（跨机房强一致代价极大）。
• 单元化是异地多活的关键：用户/数据按维度切分，避免跨单元访问。
• 跨机房事务是大坑：尽量业务拆分避免跨机房事务，用 Saga 替代 2PC。

踩坑案例

• 现象：测试环境多活正常，生产上数据各种不一致。 原因：跨机房数据同步有延迟，却按强一致设计。解决：设计即按最终一致 + 关键数据补偿机制 + 定期一致性校验修复。

常见误解

• 以为多活就是「多部署几套服务」→ 真正的难点是数据同步 + 流量调度 + 冲突解决。
• 以为双活 = 热备 → 热备不接流量，双活是两机房同时接流量。

关联

• 一致性理论：概念卡片：分布式一致性理论
• 源：B40-资源/语雀-Code-Summary/Middleware/Cache&HighAvailability/HighAvailabilityTheory（2 篇：双活设计 + 得物异地多活改造）