面试考察点
- 是否区分主节点职责与数据请求协调职责。
- 能否说明多数派对防止双主决策的作用。
- 是否知道现代版本使用自动选举配置而非旧参数经验。
核心答案
主节点负责集群状态变更，如索引元数据、分片分配和节点加入退出，不负责承载所有数据读写。现代 Elasticsearch 通过具备主资格节点的多数派选举和集群状态发布避免网络分区两侧同时形成有效主集群。
生产通常部署三个稳定的 master-eligible 节点，跨故障域分布，并避免让它们承受过重查询、写入或长时间 GC。
选举与发布
候选节点需要获得法定多数支持，集群状态更新也需可靠发布和确认。失去多数派的一侧不能继续进行需要主节点的变更，这是用部分可用性换取一致决策。
主节点究竟负责什么
主节点维护 cluster state：节点列表、索引 mapping/settings、分片分配、路由表和任务状态。数据节点执行写入、搜索和 merge；协调节点接收请求并扇出/归并；ingest 节点可负责预处理。角色可以混合，但生产大集群常把稳定主节点与高查询/高写入负载隔离。
主节点不承载所有业务请求，并不意味着它可以无限小。集群 state 很大、索引数量过多、频繁创建删除索引和大量分片会让状态发布、选举和 heap 压力显著增加。
多数派如何避免双主
假设 3 个 master-eligible 节点在网络分区后分成 2+1：2 节点一侧拥有多数，可以继续选主；1 节点一侧没有多数，不能形成有效主集群。若配置不当允许两侧都自认为主，双方可能发布互相冲突的分配与元数据，恢复时很难合并，这就是脑裂风险。
因此生产通常使用奇数个独立主资格节点并跨故障域，至少保证任意一个故障仍有多数。节点数不是越多越好，更多选举成员也会增加通信和状态发布成本。
初始集群启动与滚动变更
初始选举需要明确集群名称、节点发现和 bootstrap 配置。初始 master 列表只用于第一次形成集群；集群已建立后，重复修改 bootstrap 或 cluster name 可能把重启节点误组装成一个新集群。升级和重启采用滚动策略，先确认剩余主节点有多数和稳定状态，再处理下一台。
失主时的观测指标
关注 master election 次数、cluster state publication 延迟、pending tasks、节点连接、GC pause、网络丢包和 CPU。主节点频繁 GC 会被其他节点视为失联，触发不必要的选举；大量索引创建和模板更新也会排队阻塞状态变更。
排查时保存主节点日志、线程转储和集群状态快照，不要在故障中反复重启所有节点，这可能把短暂网络问题放大成全群不可用。
运维实践
首次组建集群的 bootstrap 配置只用于初始启动，集群形成后不应重复配置成新集群。监控主节点 GC、集群状态队列、网络延迟和频繁选举，节点重启采用滚动方式。
常见误区
协调节点不等于主节点，任何接收请求的节点都可能协调查询。照搬旧版本 minimum_master_nodes 配置到现代版本并不正确，应以所用版本官方机制为准。
高频追问与参考回答
追问：两个主资格节点够吗？
从多数派容错看，两个节点失去任意一个就无法形成多数，且网络分区难以兼顾可用性；通常使用三个独立主资格节点容忍一个故障。
追问：主节点越多越可靠吗？
需要足够多数派和故障域隔离，但过多会增加选举通信、集群状态发布和运维复杂度。三个主资格节点是很多中型集群的常见起点，不是所有规模的固定答案。
追问：网络延迟会导致脑裂吗？
现代多数派选举旨在防止双主，但长延迟、丢包和频繁节点失联会导致选举抖动、请求失败和状态发布延迟。应修复网络和资源问题，而不是只延长超时。
追问：为什么索引数量过多会影响选主？
索引、分片和 mapping 都会进入 cluster state，状态越大，发布和序列化越慢，主节点 heap 和 CPU 压力越高。时间序列应使用 rollover、数据流和合理保留。
总结
选主的核心是对集群元数据形成唯一多数派决策，稳定主节点、合理拓扑和版本正确的配置比“调一个防脑裂参数”更重要。
机制全景图
下面把「Elasticsearch 集群选主和脑裂如何处理？」从输入到结果压缩成一条可复述的主链路。面试时先用图建立全局坐标，再进入局部实现，能避免只背零散结论。
flowchart LR
A["节点发现并加入"]
A --> B["Master-eligible 节点投票"]
B --> C["选出唯一 Master"]
C --> D["发布集群状态"]
D --> E["故障后重新选举并恢复分片"]
完整链路：从输入到结果
沿着「节点发现并加入 → Master-eligible 节点投票 → 选出唯一 Master → 发布集群状态 → 故障后重新选举并恢复分片」观察输入、状态与输出，下面每个阶段都对应一个可以在源码、日志或系统表中验证的位置。
1. 节点发现并加入
discovery.seed_hosts 和 initial_master_nodes 只服务发现/首次引导，错误重复引导可能形成独立集群。
2. Master-eligible 节点投票
符合任期与投票配置的多数派才能选主，避免网络分区两侧都合法修改 Cluster State。
3. 选出唯一 Master
Master 管理元数据、分片分配和状态发布，不负责汇总所有业务查询数据。
4. 发布集群状态
Cluster State 先发布给节点并等待确认，字段/索引和分片过多会放大发布成本。
5. 故障后重新选举并恢复分片
Master 故障后新任期选举，随后处理未分配分片和恢复；数据节点 I/O 压力可能使控制面更慢。
源码与实现定位
| 入口 | 阅读重点 |
|---|---|
| Coordinator/CoordinationState | term、投票与发布 |
| _cluster/pending_tasks | 控制面积压 |
源码或系统表应按上表顺序追踪：先确认入口实际走到哪条路径，再用运行时数据验证，而不是仅凭类名或配置推测。
参数配置与可复现实验
GET _cluster/state/master_node,metadata
GET _cluster/pending_tasks
暂停 Master、断网和制造长 GC，记录选举与 Cluster State 发布时间。
验证步骤与预期结果
1. 固定输入和基线
先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「pending tasks」为主基线，记录值应满足「记录稳态基线」；同时保存 Master 选举次数、Cluster State 发布时间，使后续变化能够回到同一时间轴比较。
2. 从实现入口确认路径
在「Coordinator/CoordinationState」确认请求确实进入「term、投票与发布」对应的实现，再沿「_cluster/pending_tasks」观察「控制面积压」。如果入口路径都未命中，就不应继续调整下游参数，而应先检查调用条件、版本或路由是否与假设一致。
3. 注入本文特有的失败模式
优先复现「重复设置 initial_master_nodes 误建新集群」，并把单一变量逐级放大，直到「pending tasks」越过「超过基线2倍」。随后再分别验证「Master 节点偶数且故障域分布不当」和「节点短暂抖动触发昂贵分片搬迁」，三类故障分开执行，避免多个变量同时变化而无法归因。
4. 执行止损和根因修复
第一轮只应用「3 个专用 Master 跨域」，确认它能控制影响范围；第二轮应用「initial_master_nodes 仅首次」，验证核心链路恢复；最后落实「先稳控制面再恢复分片」，消除同类问题再次出现的条件。每一步都保留变更前后数据，不用“感觉变快了”替代测量。
5. 通过退出条件
实验只有同时满足三项才算通过：「pending tasks」回到「记录稳态基线」、「P99」回到「小于业务预算」、「结果差异」回到「0」，并且业务结果差异为零。若性能恢复但结果不一致，仍应视为失败；若指标恢复后很快再次越线，则说明只完成了临时止损，没有消除根因。
量化基线
| 指标 | 样例基线/口径 | 风险线 | 结论 |
|---|---|---|---|
| pending tasks | 记录稳态基线 | 超过基线2倍 | 按实现入口定位 |
| P99 | 小于业务预算 | 突破预算 | 停止扩量 |
| 结果差异 | 0 | 任意非零 | 回滚并重建 |
这些数值是实验口径或示例告警线，不是可复制到所有系统的固定答案；上线阈值应由本系统稳态、峰值和故障演练共同确定。
事故复盘：网络抖动时集群状态频繁变红
Master 与数据节点混部且堆压力高，长 GC 被其他节点视为失联，反复选举与分片重分配。隔离专用 Master、稳定堆和调整故障检测前先解决停顿根因后恢复。
| 失败模式 | 首要证据 | 第一处置动作 |
|---|---|---|
| 重复设置 initial_master_nodes 误建新集群 | Master 选举次数 | 3 个专用 Master 跨域 |
| Master 节点偶数且故障域分布不当 | Cluster State 发布时间 | initial_master_nodes 仅首次 |
| 节点短暂抖动触发昂贵分片搬迁 | pending tasks | 先稳控制面再恢复分片 |
发布与回滚检查点
- 发布前：确认「Coordinator/CoordinationState」对应实现和上述配置在目标版本仍然有效，并保存「pending tasks」基线。
- 灰度中：同时观察 Master 选举次数、Cluster State 发布时间、pending tasks；任一指标越过表中风险线，就停止继续扩量。
- 回滚时：先执行「3 个专用 Master 跨域」控制影响，再回退代码或参数；涉及持久状态时必须额外核对结果差异。
- 发布后：至少覆盖一个完整峰值周期，确认「重复设置 initial_master_nodes 误建新集群」没有再次出现，才关闭变更观察窗口。
方案对比与选型
| 方案 | 更适合的场景 | 主要收益 | 代价与边界 |
|---|---|---|---|
| 专用 Master 节点 | 中大型生产集群 | 控制面资源隔离 | 额外节点成本 |
| 混合角色 | 小型非关键集群 | 资源利用率高 | 数据查询/GC 会影响选举 |
| Voting-only 节点 | 需增加投票容错但不承担 Master | 提高多数派稳定性 | 仍需资源和拓扑规划 |
选型至少带上 文档规模、分片数、字段基数、查询并发和写入速率，并用上面的量化基线验证；未知数据应明确为待测假设。
设计边界与工程取舍
集群控制面依赖多数派与稳定状态发布；先保证 Master 资源和故障域，再讨论数据节点数量。
工程落地遵循：先设计 Mapping 与分片，再优化查询；任何调优都要控制扫描与内存放大。回答时直接引用「Coordinator/CoordinationState」、配置实验和事故数据，比复述固定模板更有说服力。