仲裁与法定人数 Quorum
用多数派机制决定谁能成为主：n 个投票成员需要 n/2+1 同意才能选出主节点，避免 1:1 的对等僵局。投票成员通常取奇数（3、5）并跨故障域分布；只有两个节点时引入见证节点（witness）提供决胜票。仲裁设计的核心目标很直接——任何单点故障都不应同时影响多数派。
基本信息
| 适用平台 | Pacemaker/Corosync、etcd、ZooKeeper、数据库集群等 |
|---|---|
| 基本规则 | 多数派当选：n 个投票成员需 n/2+1 同意 |
| 部署建议 | 投票成员取奇数，分布在不同的故障域 |
| 见证节点 | 双节点场景引入仲裁者打破平票，通常不承载业务数据 |
典型使用场景
- 数据库主备集群：决定故障时哪一侧成为主
- 分布式协调服务（etcd、ZooKeeper）：保证同一时刻只有一个主
- 跨机房集群：在第三处放仲裁节点，避免机房间网络分区导致双主
- 集群扩容规划：调整投票成员数量时重新评估多数派门槛
- 演练验证：模拟单点故障，确认集群仍能选出主并继续服务
部署组合示意
部署组合示意
# 同城：主 + 备 + 仲裁节点（第三处小节点或云上轻量实例）
# 跨城：主 + 备 + Witness（放在第三个故障域）
# 三节点集群：节点分布在三个机柜或三个可用区，任意一个故障仍有多数派
# 原则：任何单点故障都不应同时影响多数派
# 观测：仲裁节点或见证节点的网络可达性要纳入监控与告警
# 禁忌：把仲裁与主节点放在同一机柜、同一供电、同一交换机下常见配置对比
| 配置 | 容错能力 | 风险 |
|---|---|---|
| 双节点无仲裁 | 不能自动定主 | 分区时各认为自己是主，形成双主 |
| 双节点加仲裁 | 容忍单点故障 | 仲裁与主同机房时失去意义 |
| 三节点奇数 | 容忍一个节点故障 | 节点集中在一个机柜时同时失效 |
| 五节点 | 容忍两个节点故障 | 跨域通信延迟影响写性能 |
仲裁节点不承载业务数据，但它的网络可达性决定集群在分区时的行为，同样要纳入监控。仲裁的决策规则一旦确定，变更要谨慎：缩小多数派门槛的窗口内集群会变得脆弱。