ES常识7：ES8.X集群允许4个 master 节点吗

在 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 节点专注集群管理，避免数据操作（如索引写入）干扰主节点稳定性。
• 配置示例：

  # 前 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 角色，并严格控制节点故障风险。