2、多活架构核心模式：同城双活、异地多活、两地三中心、单元化架构
多活架构的核心目标是消除单点故障，使业务在部分站点失效时仍能持续对外服务。根据地理分布距离、数据同步策略和流量调度粒度的不同，业界形成了四种主流模式：同城双活、异地多活、两地三中心和单元化架构。每种模式在容灾等级、成本、复杂度上各有取舍。
2.1 模式对比总览
下表从关键维度对比四种核心模式，帮助快速建立全局认知：
| 维度 | 同城双活 | 异地多活 | 两地三中心 | 单元化架构 |
|---|---|---|---|---|
| 物理距离 | 同城 10~50 km | 异地 500~2000 km | 同城 + 异地 | 同城 / 异地均可 |
| RPO（恢复点目标） | 0 ~ 秒级 | 秒级 ~ 分钟级 | 秒级（同城） | 秒级（单元内） |
| RTO（恢复时间目标） | 分钟级 | 分钟级 | 分钟级 ~ 小时级 | 秒级 ~ 分钟级 |
| 流量调度粒度 | 全局负载均衡 | DNS / GSLB | 主备切换 | 用户维度分片 |
| 数据一致性 | 强一致性（同城） | 最终一致性 | 强一致 + 异步 | 单元内强一致 |
| 典型成本 | 中 | 高 | 高 | 极高 |
| 适用场景 | 金融核心、交易 | 互联网大流量 | 监管合规要求 | 超大规模用户 |
2.2 同城双活
同城双活是在同一城市部署两个独立数据中心，均承载业务流量，形成“双活”状态。两个中心通过光纤专线互联，距离通常在 10~50 公里以内，网络延迟低于 1ms，可实现数据库层面的同步复制。
核心特征：两个中心同时读写，数据强一致，故障时秒级切换，用户无感知。
技术要点：
- 存储层：采用分布式存储或 SAN 同步复制，保证数据零丢失。
- 应用层：无状态化设计，通过全局负载均衡（GSLB）分发流量。
- 网络层：大二层网络或 VXLAN 打通，实现 IP 漂移。
实战建议：同城双活是“两地三中心”的基础，建议先在同城范围内验证双活能力，再向异地扩展。
2.3 异地多活
异地多活将数据中心部署在不同城市，距离通常超过 500 公里。所有数据中心同时对外提供服务，通过 DNS 或 GSLB 按地域、运营商或权重进行流量调度。异地多活的核心挑战是数据冲突和网络延迟。
关键约束：异地多活必须接受最终一致性，无法保证强一致。设计时需通过业务拆分（如按用户 ID 哈希）减少跨中心数据依赖。
数据同步策略：
- 单向同步：主中心写，备中心读，适合读多写少场景。
- 双向同步：各中心均可写，需引入冲突检测与合并机制（如 CRDT、最后写入胜利）。
- 单元化同步：每个用户固定在一个单元内读写，单元间异步复制元数据。
典型实践：电商大促时，将华东用户流量导入上海数据中心，华南用户导入广州数据中心，实现流量就近接入。
2.4 两地三中心
两地三中心是“同城双活 + 异地灾备”的组合模式：在同城部署两个数据中心（双活），在异地部署一个灾备中心（冷备或温备）。同城中心间采用同步复制，异地中心采用异步复制。该模式在金融、政务等强监管行业广泛采用。
容灾等级：同城双活保障日常高可用，异地灾备应对城市级灾难（如地震、洪水）。
数据流向：
- 同城中心 A 和 B 同时承载读写流量，数据实时同步。
- 异地灾备中心 C 从同城中心异步拉取数据，通常延迟在分钟级。
- 同城双活均不可用时，手动或自动切换至异地灾备中心。
注意：异地灾备中心通常不承载流量，资源利用率低。切换时需考虑数据一致性校验和 DNS 缓存刷新时间。
2.5 单元化架构
单元化架构是异地多活的进阶形态，将用户和数据按维度（如用户 ID、地域）划分为多个单元，每个单元是一个独立、自包含的部署单元，包含完整的应用、数据库、缓存和中间件。单元间通过异步消息同步元数据，单元内实现强一致。
核心原则：“单元封闭、流量封闭、数据封闭”。一个用户的所有请求只在一个单元内完成，不跨单元调用。
单元划分策略：
| 策略 | 划分维度 | 优点 | 缺点 |
|---|---|---|---|
| 用户 ID 哈希 | user_id % N | 均匀分布，实现简单 | 扩缩容需重新哈希 |
| 地域划分 | 用户归属地 | 数据合规，就近接入 | 单元间负载不均 |
| 业务维度 | 业务线（交易/社区） | 业务隔离，故障隔离 | 跨单元业务复杂 |
避坑指南：单元化架构对基础设施要求极高，需自研或深度定制分布式中间件（如单元化路由、全局 ID 生成器、跨单元事务协调器）。不建议中小团队直接采用。
2.6 模式选型建议
在实际项目中，选择哪种多活模式取决于业务规模、预算、监管要求和团队技术能力。以下是一份快速选型指南：
选型决策树：
- 如果业务在单一城市，预算有限 → 同城双活
- 如果业务覆盖全国，需要就近接入 → 异地多活
- 如果监管要求异地灾备，且已有同城双活 → 两地三中心
- 如果用户量过亿，需要极致扩展性和故障隔离 → 单元化架构
常见误区：
- 误区一：认为异地多活可以做到强一致。实际上，物理距离带来的延迟无法消除，必须接受最终一致性。
- 误区二：两地三中心的异地灾备中心可以自动接管。多数场景下需要人工确认数据一致性后再切换。
- 误区三：单元化架构可以一步到位。建议先从同城双活起步，逐步演进到单元化。