3. 节点角色与资源规划诊断
Elasticsearch 集群的稳定性，很大程度上取决于节点角色是否被正确划分、资源是否与角色匹配。很多“集群变慢”“查询超时”“写入被拒”的根因，并不是分片数量或磁盘容量，而是角色混部导致的资源争抢，或者角色配置冲突引发的脑裂风险。本节围绕四类核心角色展开：Master、Data、Ingest、Coordinating，讲清它们各自“该做什么”，再落到“怎么诊断资源瓶颈、角色冲突与脑裂风险”。
四类角色的职责边界
Master 节点负责集群级元数据管理：索引的创建与删除、分片分配决策、节点上下线感知、集群状态（cluster state）的发布。它不存储业务数据，也不处理文档的读写请求。Master 的负载特征是“低吞吐、强一致、对延迟敏感”，一旦 Master 频繁 Full GC 或网络抖动，整个集群会出现元数据更新停滞，表现为创建索引卡住、分片无法重新分配。
Data 节点承担分片的存储与读写执行，是 CPU、内存、磁盘 IO 消耗最大的角色。它负责文档的索引、检索、聚合、段合并（merge）。Data 节点的资源瓶颈通常最先体现在磁盘 IO 和堆内存上。
Ingest 节点在文档写入前执行预处理管道（pipeline）：字段解析、grok 提取、日期处理、enrich 富化等。它消耗 CPU 明显，尤其是正则表达式密集的 grok 处理器。Ingest 节点不存储数据，但会参与写入链路。
Coordinating 节点（协调节点）负责接收客户端请求、将请求分发到相关分片、汇总各分片结果并返回。它本身不存数据、不做主节点决策，但需要足够的堆内存来聚合结果集，尤其是深度聚合和大量分片场景。
node.roles 的节点会同时承担上述所有角色，这在生产环境是高风险配置。显式声明角色是资源规划的第一步。角色划分的典型配置
下面是一组生产环境常见的角色声明示例，用于说明“职责分离”的落地方式：
# 专用 Master 节点（3 台，满足多数派）
node.roles: [ master ]
node.master: true
# 专用 Data 节点（热数据）
node.roles: [ data_hot, data_content ]
# 专用 Ingest 节点
node.roles: [ ingest ]
# 专用 Coordinating 节点（仅协调，不存数据）
node.roles: [ ]
注意最后一行：node.roles: [] 表示该节点不承担任何数据、主节点或 ingest 角色，只做请求协调。这是 Coordinating 节点的标准写法。如果写成 node.roles: [ ] 之外还保留了 data，那它就不是纯协调节点。
资源瓶颈识别：从指标到判断
诊断资源瓶颈，关键是“角色—指标—阈值”三者对应。下面这张图展示了四类角色各自的资源消耗路径与典型瓶颈点，可作为排查时的对照参考。
结合上图，实际排查时可以按以下顺序定位：先看 _cat/nodes?v&h=name,node.role,heap.percent,ram.percent,cpu,load_1m，确认每个节点的角色与实时负载；再用 _nodes/stats 查看各角色的具体指标。例如 Data 节点重点看 indices.store.throttle 和 merges.total_time_in_millis，Ingest 节点看 ingest.total.time_in_millis，Coordinating 节点看 thread_pool.search.queue 是否持续堆积。
角色冲突的典型表现与处理
角色冲突最常见的是“Master + Data 混部”。当 Data 节点执行大聚合或段合并时，CPU 和 IO 被占满，Master 线程得不到调度，导致集群状态更新延迟。表现是：_cluster/health 返回的 task_max_waiting_in_queue_millis 升高，创建索引或更新 mapping 变慢。处理方式是拆分角色，让 Master 只做元数据管理。
另一种冲突是“Ingest + Data 混部”。写入高峰期，grok 解析消耗大量 CPU，直接拖慢同一节点上的查询响应。诊断方法是观察 ingest.total.time_in_millis 与 search.query_time_in_millis 是否同步上升。若同步上升，说明两者在争抢 CPU，应考虑将 Ingest 独立部署。
Coordinating 节点如果同时承担 Data 角色，大聚合的中间结果会占用堆内存，可能触发 Data 节点的 GC 压力。纯 Coordinating 节点的堆内存建议不低于 8GB，且 indices.query.bool.max_clause_count 等参数需要根据聚合规模调整。
脑裂风险排查清单
脑裂的本质是集群被网络分区后，两个分区各自选出了 Master，导致元数据分叉。排查时逐项核对：
| 检查项 | 正确做法 | 风险信号 |
|---|---|---|
| Master 候选数量 | 3 或 5 台，奇数 | 2 台或 4 台，无法形成多数派 |
| discovery.seed_hosts | 列出全部 Master 候选地址 | 只列部分，分区后无法发现彼此 |
| node.roles | Master 节点仅含 master | 含 data/ingest，负载抖动误触发选举 |
| initial_master_nodes | 仅首次引导使用 | 长期保留，重启后可能重复引导 |
| 网络延迟 | Master 间 RTT < 10ms | 跨机房部署，心跳超时误判 |
资源规划的实际判断依据
资源规划不是“给每个节点平均分配”，而是按角色定基线。以下是一组参考基线（示例值，需按实际业务调整）：Master 节点堆内存 4–8GB，CPU 4 核即可，磁盘不需要大容量；Data 节点堆内存不超过物理内存的 50%，且不超过 31GB（避免指针压缩失效），磁盘建议 SSD，保留 20% 以上空闲；Ingest 节点 CPU 核数应与 pipeline 复杂度匹配，grok 密集场景建议 8 核以上；Coordinating 节点堆内存 8–16GB，CPU 8 核以上，网络带宽要充足。
诊断时，可以用 _cat/allocation?v 查看分片分布是否均衡，用 _cat/thread_pool?v&h=node_name,name,active,queue,rejected 查看各线程池的排队与拒绝情况。如果 write 线程池出现 rejected，说明 Data 节点写入压力过大；如果 search 线程池 queue 持续大于 0，说明 Coordinating 或 Data 的查询处理能力不足。
最后要强调：角色划分和资源规划是“先设计、后验证、再调整”的循环。每次扩容或业务变更后，都应重新核对角色配置与资源基线，避免因为节点角色漂移而引入新的瓶颈或脑裂隐患。