偶数节点易致选举失败，因网络分区时可能平票；奇数节点（如3、5）可避免此问题，arbiter虽省成本但不提供冗余或读负载分担，3节点适合中小业务但须跨物理位置部署，副本集最多7个投票节点。
为什么偶数节点会导致选举失败
副本集依赖“多数派投票”机制选出 Primary。当节点数为偶数（比如 2 或 4），网络分区或节点宕机时极易出现 votes == ½ total 的平票局面，导致无法达成多数，选举卡住、集群不可写。这不是理论风险——真实故障中，一次临时网络抖动就可能触发该问题。
奇数节点（如 3、5、7）天然规避平票：3 节点只要 2 票即可过半，即使 1 个宕机，剩余 2 个仍能完成选举；5 节点允许最多 2 个失效后继续服务。
- 投票节点上限是
7，超过需用隐藏节点或延迟节点替代，但它们不参与选举 -
arbiter是纯投票节点，不存数据，可部署在低配机器甚至应用服务器上，但它本身也计入投票总数 - 若已有 2 个数据节点，加 1 个
arbiter构成 3 投票节点，比加第 3 个数据节点更省磁盘和内存
arbiter 真的能“节省硬件成本”吗
能，但有明确前提：它只在你**无法新增数据节点**时才划算。因为 arbiter 不提供冗余、不支持读取、不加速同步——它只解决“能不能投出 Primary”这一个问题。
如果你本就可以部署第 3 个数据节点，那直接上数据节点远比加 arbiter 更健壮：它既提升容灾能力，又支持 secondaryReads 分流查询压力，还能在主节点恢复前承担部分只读流量。
-
arbiter必须能连通所有投票节点，否则会拖慢心跳检测，反而延长故障发现时间 - 不要把
arbiter和主节点/从节点部署在同一台物理机或同一可用区，否则单点故障会同时干掉数据+投票能力 - 生产环境用
arbiter前，先确认你的监控已覆盖rs.status().members[n].stateStr和lastHeartbeatRecv
3 节点副本集是否足够用于生产
对中小规模业务，标准三节点（1 Primary + 2 Secondary）是最常用且平衡的选择：它满足自动故障转移、读写分离、数据冗余三项基本要求，且运维复杂度可控。
但要注意三个硬约束：
- 三个节点必须分布在至少两个物理位置（例如不同机架、不同 AZ），避免单点物理故障击穿全部节点
- 所有节点的
priority应设为默认1，除非你有强主节点偏好；否则人为调高某节点priority可能导致非预期的主切行为 - 务必关闭
slaveDelay和hidden等非常规配置，除非你明确需要延迟备份或专用报表节点
为什么不能无限制堆砌节点数
副本集最大只允许 7 个投票节点，这是硬限制。再多节点只能设为 votes: 0，即不参与选举——它们只是数据副本，对高可用性无实质提升，反而增加同步开销和配置管理负担。
每多一个投票节点，心跳通信量、选举协商轮次、oplog 同步压力都会线性上升。实测显示：从 3 节点扩到 5 节点，平均选举耗时增加约 40%，而容灾能力提升有限（仅多容忍 1 个节点失效）。
- 优先考虑提升单节点性能（SSD、足够内存、合理
oplogSize）而非盲目加节点 - 跨地域部署时，异地节点应设为
votes: 0, priority: 0，避免因网络延迟引发误判和反复选举 - 用
rs.conf()检查每个成员的votes和priority值，确保没有意外开启投票权
实际部署中，最常被忽略的是节点间时钟同步与 DNS 可解析性——哪怕投票逻辑完美，Failed to heartbeat 或 nodename nor servname provided 这类底层错误照样让整个副本集瘫痪。
