多机房的三种模式
多机房部署形态按 RPO 与 RTO 划分：主备模式异步复制，站点故障时切换，代价是可能丢一部分数据；同城双活靠低延迟链路加仲裁节点，能做到接近零丢失；单元化多活把数据按单元切分，故障影响面最小但改造量最大。共识类存储跨机房部署时，写入延迟取决于成员分布与多数派落点。
模式对照
| 模式 | RPO / RTO 倾向 | 关键约束 |
|---|---|---|
| 主备（异步复制） | RPO 大于 0，RTO 分钟级 | 切换脚本与数据追赶必须演练 |
| 同城双活 | RPO 接近 0，RTO 秒级 | 需要仲裁节点与脑裂防护 |
| 单元化多活 | 单元内自洽，故障影响面小 | 跨单元聚合与路由改造成本高 |
基本信息
| 多数派落点 | 副本跨机房时，写确认需要跨机房往返，延迟由链路决定 |
|---|---|
| 副本分布 | 两机房平均分布时任一机房故障都可能选不出多数派 |
| 读偏好 | 可就近读从节点以降低延迟，但要接受读到的可能是旧数据 |
| 异地复制 | 搜索引擎类可用跨集群复制做异地副本，写入仍在主集群 |
| 切换演练 | 切换时长与数据丢失量必须实测，而非估算 |
典型使用场景
- 同城容灾：两个机房加一个仲裁点，避免单机房故障导致整体不可用
- 异地备份与只读副本：主集群写入，异地提供查询与恢复能力
- 单元化改造：用户按维度分单元，跨单元的请求尽量减少
- 故障演练：定期模拟机房级故障，验证切换流程与耗时
- 容量规划：多数派落点与专线带宽一起决定集群规模上限
机房感知部署（MongoDB 分区示意）
机房感知部署（MongoDB 分区示意）
// 给分片打机房标签，并把租户的数据范围固定到机房
sh.addShardToZone("shardA", "dc-east")
sh.updateZoneKeyRange("app.users", { region: "east" }, { region: "east~" }, "dc-east")
// 读偏好与写关注一起决定延迟与一致性
// 连接串：readPreference=nearest
// 写入：writeConcern { w: "majority" } —— 跨机房部署时先确认多数派落点与链路延迟先量化可接受的 RPO 与 RTO 再选模式：多数业务不需要跨城强一致，但必须能说清故障时丢多少数据、多久恢复。
副本成员平均分布在两个机房时，任一机房整体故障都可能无法形成多数派，仲裁点必须放在第三个故障域。