在 Elasticsearch（ES）中，4 个 Master 节点的集群可以运行，但存在稳定性风险，且不符合官方推荐的最佳实践。以下从选举机制、故障容错、资源消耗三个维度详细分析：
一、4 个 Master 节点的可行性：基于选举机制
ES 的主节点选举依赖 多数派（Quorum） 原则，通过 minimum_master_nodes 参数控制，计算公式为：
minimum_master_nodes = (主节点候选数 / 2) + 1（向上取整）。
4 个 Master 节点的选举逻辑
- 主节点候选数（n） ：4（4 个节点均设置
node.master: true）。 - minimum_master_nodes ：
(4/2)+1=3（ES 会自动计算，也可手动设置）。 - 选举条件：集群中必须有至少 3 个 Master 节点保持通信（形成多数派），才能选举出主节点。
集群运行状态
- 正常情况：4 个节点均在线时，可选举出主节点，集群正常运行。
- 1 个节点宕机：剩余 3 个节点（≥3），仍能形成多数派，选举新主节点，集群保持可用。
- 2 个节点宕机 ：剩余 2 个节点（ < 3），无法形成多数派，集群进入 无主状态（Split Brain 风险），无法处理索引/查询请求。
二、4 个 Master 节点的潜在问题
尽管技术上可行，但 4 个 Master 节点的集群存在以下缺陷：
1. 容错能力弱于奇数节点
ES 推荐使用 奇数个 Master 节点（如 3 个），核心原因是奇数节点的容错能力更强：
- 3 个 Master 节点 ：
minimum_master_nodes=2，允许 1 个节点宕机（3-1=2≥2）。 - 4 个 Master 节点 ：
minimum_master_nodes=3，仅允许 1 个节点宕机（4-1=3≥3）。
若 2 个节点宕机（4-2=2<3），集群将无法选举主节点，而 3 节点集群在 1 个节点宕机时仍稳定（3-1=2≥2）。
【这点有点反常识，一般认为master节点越多容错应该越强】
2. 网络通信开销更大
Master 节点需维护集群状态（如分片分配、节点健康），并通过 Zen Discovery 协议 （ES 7.x 前）或 Election 协议（ES 7.x+）同步信息。4 个节点的集群需更多网络交互（如心跳检测、选举投票），可能导致：
- 选举延迟增加（尤其在跨机房部署时）。
- 集群状态同步耗时更长（状态变更需广播到 4 个节点）。
3. 资源浪费
每个 Master 节点需要独立的 CPU、内存资源（推荐至少 2 核 4GB 内存）。4 个节点比 3 个节点多消耗 33% 的资源，但未带来对应的容错提升，属于资源浪费。
三、官方推荐的 Master 节点数
ES 官方文档明确建议 生产环境使用 3 个 Master 节点（奇数），原因如下：
- 最优容错性：3 节点允许 1 个节点宕机（占比 33%），4 节点仅允许 1 个节点宕机（占比 25%），容错能力更弱。
- 最小资源消耗：3 节点比 4 节点节省 25% 的硬件成本，同时满足多数派选举要求。
- 稳定性验证：奇数节点的选举算法（如 Raft）经过长期验证，能有效避免脑裂。
四、4 个 Master 节点的替代方案
若因特殊原因（如跨机房部署）需要 4 个节点，可通过以下方式优化：
1. 分离 Master 与 Data 角色
将 4 个节点中的 3 个设为 专用 Master 节点 （仅负责集群管理），第 4 个节点设为 数据节点 （node.data: true，node.master: false）。
-
优势：Master 节点专注集群管理，避免数据操作（如索引写入）干扰主节点稳定性。
-
配置示例 ：
yaml# 前 3 个节点（Master 专用） node.master: true node.data: false node.ingest: false # 第 4 个节点（数据节点） node.master: false node.data: true
2. 调整 minimum_master_nodes
手动设置 minimum_master_nodes=2（不推荐，违反多数派原则），但会导致脑裂风险：
- 风险：若 2 个节点因网络分区形成两个独立集群（各 2 节点），可能同时选举主节点，导致数据不一致。
- 结论：仅适用于测试环境，生产环境严禁使用。
总结
4 个 Master 节点的集群可以运行 ，但存在容错能力弱、通信开销大、资源浪费等问题，不符合 ES 最佳实践。生产环境推荐使用 3 个 Master 节点（奇数），既能保证高可用性，又能优化资源利用。若因特殊需求需部署 4 节点，建议分离 Master 与 Data 角色，并严格控制节点故障风险。