4. 容灾架构模式选型
容灾架构模式选型，本质上是在RTO（恢复时间目标）、RPO（恢复点目标）、成本与运维复杂度四个约束之间做取舍。很多团队在选型时容易陷入“越先进越好”的误区，直接上异地多活，结果发现数据一致性冲突、链路延迟、流量调度复杂度远超预期。正确的做法是先明确业务对 RPO/RTO 的真实要求，再匹配架构模式。
下面先给出四种主流模式的核心特征对比，再逐一展开其数据流与适用边界。
| 模式 | 典型 RPO | 典型 RTO | 资源成本 | 核心难点 |
|---|---|---|---|---|
| 主备（冷/温/热备） | 分钟级～小时级 | 分钟级～小时级 | 低 | 切换判定、数据补齐 |
| 同城双活 | 秒级（近 0） | 秒级～分钟级 | 中高 | 双写一致性、脑裂 |
| 两地三中心 | 同城近 0，异地分钟级 | 同城秒级，异地分钟级 | 高 | 异地链路带宽、仲裁 |
| 异地多活 | 秒级（单元内近 0） | 秒级～分钟级 | 很高 | 单元化路由、跨单元数据同步 |
从数据流角度看，四种模式的差异集中在“写入路径”和“故障切换路径”上。下图展示了四种模式的拓扑与数据流向对比，其中实线表示同步复制，虚线表示异步复制，箭头方向为数据写入方向。
接下来逐一说明每种模式的关键实现要点与选型判断依据。
主备模式：最简单，但切换是最大风险点
主备模式的核心是“一写一备”。主节点承担全部读写，备节点通过日志或存储层复制保持数据同步。按备节点状态可分为冷备（仅数据备份，无运行实例）、温备（实例运行但不接流量）、热备（实例运行且可快速接管）。
实际落地时，关键不在复制本身，而在切换判定与数据补齐。以 MySQL 主备为例，常见做法是主库开启 binlog，备库通过 CHANGE MASTER TO 指向主库并启动 START SLAVE。切换前必须确认 Seconds_Behind_Master 是否接近 0，否则会丢失数据。若主库已不可访问，需从备库执行 STOP SLAVE，记录当前 binlog 位点，再提升为主库并修改应用连接串。这个过程在无自动化工具时通常需要 5～30 分钟，RTO 难以压缩到秒级。
同城双活：RPO 接近 0，但要解决双写与脑裂
同城双活指两个机房同时对外提供服务，通常采用“双写”或“主写+同城同步复制”两种方式。双写模式下，两个机房都接受写入，通过分布式数据库或中间件保证一致性；同步复制模式下，写入需等待同城备机房确认后才返回成功，因此 RPO 接近 0，但写入延迟会增加 1～3ms。
同城双活的关键约束是仲裁机制。当两个机房之间的链路中断时，必须避免两个机房都认为自己是主节点而同时写入，即“脑裂”。常见做法是引入第三个仲裁节点（可以是轻量级服务或独立机房），由仲裁节点决定哪个机房继续提供服务。仲裁节点本身不存储业务数据，只参与投票。
适用场景：支付、订单、库存等对 RPO 要求极高的核心业务，且业务部署在同一城市或同一地域内。若业务本身跨城市，同城双活无法覆盖城市级故障。
两地三中心：同城双活 + 异地灾备的组合
两地三中心是在同城双活基础上，增加一个异地灾备中心。典型结构是：同城两个中心之间同步复制，保证 RPO≈0；异地中心通过异步复制接收数据，RPO 通常在秒级到分钟级。当同城发生城市级灾难时，异地中心可接管业务，但会丢失最近一段时间的异步复制数据。
这种模式在金融、政务行业较为常见，因为它同时满足“同城高可用”和“异地数据保护”两个监管要求。代价是资源成本高，且异地链路带宽和延迟需要提前评估。以某银行示例配置为例：同城两个中心各部署 20 台数据库服务器，异地中心部署 10 台，异地复制链路带宽预留 200Mbps，异步复制延迟控制在 30 秒以内。这些参数需根据实际业务写入量测算，不能直接套用。
异地多活：单元化是前提，不是简单加机房
异地多活的核心思想是“单元化”：将用户按分片规则划分到不同单元，每个单元内闭环完成读写，单元之间通过异步复制同步数据。这样单个单元故障时，只需将该单元的用户流量切换到其他单元，影响范围可控。
异地多活不是“多部署几套”就能实现的，它要求业务具备用户分片能力、跨单元数据同步能力和全局路由能力。以用户 ID 取模分片为例，假设分片规则为 user_id % 4，则 4 个单元分别承载 0、1、2、3 号分片。当单元 0 故障时，路由层将 0 号分片流量切到单元 1，单元 1 需要能处理原本不属于它的用户数据，这要求数据同步足够及时，且业务逻辑不依赖本地缓存强一致。
异地多活的 RPO 在单元内接近 0，跨单元为秒级到分钟级；RTO 取决于路由切换速度，通常可做到秒级到分钟级。适用场景是超大规模互联网业务，且团队具备较强的分布式系统运维能力。对于中小团队，不建议直接上异地多活，可先从同城双活起步。
选型决策：从业务要求反推架构
选型时建议按以下顺序判断：
- 业务能接受多少数据丢失？ 若 RPO 必须为 0，排除主备和异步复制方案，优先同城双活或两地三中心的同城部分。
- 业务能接受多长停机？ 若 RTO 要求分钟级以内，必须有自动化切换和流量调度能力，主备模式难以满足。
- 是否需要抵御城市级灾难？ 若需要，必须引入异地中心，同城双活不够。
- 团队是否具备单元化改造能力？ 若不具备，异地多活会带来极高的运维负担，建议选择两地三中心。
- 成本预算是否允许？ 异地多活和两地三中心的资源成本通常是主备的 3～5 倍，需提前核算。
最后需要强调：容灾架构的选型不是一次性决策。随着业务规模、监管要求和团队能力变化，架构也应逐步演进。建议每半年复盘一次 RTO/RPO 实际达成情况，并结合故障演练结果调整架构模式。