前面的复制集都假设节点在同一个机房。但机房会整体故障——断电、网络中断、空调失效。三节点复制集如果都在一个机房，机房挂了就全军覆没。要扛机房级故障，必须跨可用区部署，这就是两地三中心架构。

这一篇是复制集阶段的收尾，讲清楚怎么把复制集节点分散到多个机房，让任一机房故障时集群仍能形成多数派、选出新 Primary、继续服务。

先把机制边界说清楚

跨机房部署要解决的核心矛盾是：既要数据冗余分散在多地，又要保证多数派选举能正常工作。这依赖两个机制：

  • 多数派：任何机房故障，剩下的节点要能凑出超过半数的票数选主。
  • 优先级：让 Primary 优先落在延迟低的机房（通常是主机房），避免主落到跨城异地节点导致写入延迟飙升。

两地三中心的标准形态是 5 节点跨 3 个机房：主机房 2 节点、同城备机房 2 节点、异地容灾机房 1 节点。这个配置能让任一机房故障时，剩余节点仍凑出多数派（3 票）。

两地三中心的 5 节点拓扑

两地三中心：跨可用区部署

把 5 个节点按机房分布，每个机房的角色和票数清晰：

机房 A（主机房）2 节点：Primary + Secondary，priority: 2。正常工作时 Primary 落在这里，应用就近写入，延迟最低。它贡献 2 票。

机房 B（同城备机房）2 节点：两个 Secondary，priority: 1。与 A 同城，网络延迟低（通常毫秒级）。A 机房故障时，B 接班成为新 Primary。它贡献 2 票。

机房 C（异地容灾）1 节点：一个 Secondary，priority: 0（永远不参选 Primary）。异地部署，与 A/B 跨城，网络延迟大（几十毫秒到上百毫秒）。它的作用是「凑多数派的关键第 5 票」和数据异地容灾。它贡献 1 票。

为什么是 5 节点

多数派 = 节点数 / 2 + 1，5 节点的多数派是 3。逐一分析机房故障场景：

机房 A 整体故障：剩 B(2) + C(1) = 3 票，达到多数派，B 机房选出新 Primary，集群存活。这是两地三中心最核心的价值——主机房挂了不宕机。

机房 B 故障：剩 A(2) + C(1) = 3 票，Primary 仍在 A，正常服务。B 只是少了备份。

机房 C 故障：剩 A(2) + B(2) = 4 票，远超多数派，完全正常。C 只是少了异地容灾。

关键在于：C 的那一票是 A 故障时凑出多数派的关键。没有 C，A 故障只剩 B 的 2 票，达不到 3 票多数派，集群无法选主，直接不可用。所以哪怕 C 是异地、延迟大、priority 0，它也是这套架构不可或缺的一环。

如果只有 A + B 两个机房各 2 节点（共 4 节点，多数派 3），A 故障时只剩 B 的 2 票，达不到 3 票，集群还是不可用。这就是为什么需要第三个机房——哪怕只放 1 个节点。

priority 和延迟的权衡

为什么 C 的 priority: 0？因为 C 是异地，网络延迟大。如果 Primary 落到 C，每次写入要跨城往返，延迟飙到几十上百毫秒，业务根本受不了。priority: 0 保证 C 永远不会当选 Primary，它只做数据备份和投票。

正常情况下 Primary 在 A（主机房），应用就近写，延迟低。A 故障时 Primary 切到 B（同城备），延迟也只是同城级别，可接受。只有 A 和 B 都挂了（极端情况），Primary 才可能落到 C，但那已经是灾难场景，延迟大点总比不可用好。

这个优先级设计体现了「主永远落在延迟低的机房」原则。跨地域部署不是为了把 Primary 放异地，而是为了数据冗余和容灾投票。

writeConcern 与容灾的配合

跨机房部署要配合合适的 writeConcern：

  • w: "majority"：写入要等多数派（3 节点）确认。在两地三中心里，这意味着至少 A + B 各一个，或 A + C。这保证了任何单机房故障都不丢数据。
  • 写延迟：w: "majority" 要等跨机房复制，延迟比单机房高（同城几毫秒，跨城几十毫秒）。对延迟敏感的业务要权衡。
  • w: 1：只等主确认，延迟低，但 A 故障时未同步到 B/C 的写入会回滚丢失。

核心数据用 w: "majority"，容忍跨机房延迟；非核心数据可以用 w: 1 换延迟。

部署的工程细节

网络：机房间要专线或高质量网络，保证心跳和 oplog 传输稳定。跨城网络的带宽和稳定性直接影响复制延迟。

心跳超时：跨机房部署要适当调大 electionTimeoutMillis，避免网络抖动误触发选举。但调太大会拖慢 failover。

监控：跨机房的复制延迟要重点监控，特别是 A → C 的跨城延迟。延迟过大会影响 w: "majority" 的写性能。

成本：两地三中心是 5 节点，硬件和网络成本是单机房的 5 倍。它适合对可用性要求极高的核心业务，不是所有业务都需要——普通业务同城三节点就够了。

判断框架

  • 扛单机故障：同城 3 节点复制集够用。
  • 扛机房故障：必须跨可用区，两地三中心 5 节点是标准形态。
  • 5 节点 = 主 2 + 备 2 + 异地 1，任一机房故障仍能凑出 3 票多数派。
  • 异地节点 priority: 0，保证 Primary 不落延迟大的机房。
  • 配合 w: "majority"，保证任一机房故障不丢数据。
  • 成本是单机房 5 倍，只给核心业务用，普通业务同城三节点即可。

这一篇是复制集与高可用阶段的收尾。下一阶段进入分片集群，回答「单机装不下时怎么横向扩展」。

关于十三Tech

我是十三，All in AI Agent 方向的架构师，专注 AI 工程实践。

我相信 AI 是程序员的最佳搭档，也希望帮助每一位开发者更好地驾驭 AI。

如果你想继续跟完这套「图解 MongoDB」，欢迎关注公众号 「十三Tech」。后续会按分片集群和架构选型这条线更新。

十三Tech公众号二维码