Elasticsearch中的协调节点
协调节点（Coordinating Node）是 Elasticsearch 集群中**不保存数据、只负责“跑腿”**的一种节点角色。它把一个客户端请求拆成若干子任务，分发给真正存数据的数据节点，再把各数据节点的结果聚合后返回给客户端。
1. 三种常见节点角色
| 角色 | 作用 | 典型配置 |
|---|---|---|
| Master-eligible | 负责集群管理（选主、集群状态变更）。 | node.master: true |
| Data Node | 真正存索引数据，执行增删改查、聚合等。 | node.data: true |
| Coordinating Node | 不存数据，只做请求路由、结果合并。 | node.master: false |
从 7.x 开始，每个节点默认都是隐式协调节点；只要它接收了客户端请求，就临时充当“协调节点”的角色。
但生产环境通常会把“纯协调节点”独立出来，以减轻数据节点的 CPU/内存压力。
2. 工作流程（简化版）
客户端把搜索请求发到任意节点（通常是协调节点）。
协调节点解析请求，按路由规则算出需要访问哪些 分片。
并行把子查询 转发 到对应的数据节点。
数据节点在本地执行查询、聚合，把结果返回给协调节点。
协调节点 合并、排序、分页、聚合 后，把最终结果返回给客户端。
示意图：
Client│▼
┌────────────┐
│ Coordinating│
│ Node │
└──┬──────┬───┘│ │▼ ▼
┌──────┐ ┌──────┐
│Data1│ │Data2│
└──────┘ └──────┘3. 为什么要单独部署协调节点
隔离查询压力：高并发聚合或 scroll 查询会消耗大量 CPU/堆内存，扛在数据节点上会导致节点 GC 或 OOM。
负载均衡：让协调节点专门做“网络 + 合并”，数据节点专注磁盘/索引。
安全/网关：在防火墙外放一组无数据的协调节点，避免直接暴露数据节点。
4. 如何配置纯协调节点
在 elasticsearch.yml 中：
# 只做协调，不存数据，不参与选主
node.master: false
node.data: false
node.ingest: false # 如果不用 ingest pipeline启动后，它就成为一条“只转发、不落地”的管道。
5. 常见误区
“协调节点越多越好”
错。协调节点会消耗 CPU/内存做合并、聚合；过多反而增加网络跳数。一般 1–3 台即可满足大多数场景。“协调节点必须独立部署”
错。小集群（<10 节点）完全可以由数据节点兼任；独立部署更多是为了 高并发或安全隔离。
6. 一句话总结
协调节点 = 请求入口 + 结果合并器，
不存数据但很关键，生产大集群建议独立出来，小集群可共用。