📚 课程目录第2章 Elasticsearch集群架构与角色职责

2. Elasticsearch集群架构与角色职责

Elasticsearch 从 7.x 开始把节点角色拆分为可独立配置的职责集合，这一变化的核心目的，是让集群在规模扩大后仍能保持稳定的选主、可控的容量增长和清晰的故障边界。理解角色划分，本质上是在理解“谁负责决策、谁负责存储、谁负责加工、谁负责转发”这四件事如何分工，以及分工失衡时高可用和容量会从哪里先出问题。

一、节点角色的职责边界

Elasticsearch 的节点角色由 node.roles 显式声明，常见角色包括：

master（主节点候选）：参与选主，维护集群状态（cluster state），负责索引创建、分片分配、节点加入/离开等元数据决策。它不存储业务数据，也不处理搜索请求。
data（数据节点）：存储分片、执行读写、聚合和搜索。可进一步细分为 data_hot、data_warm、data_cold、data_frozen，用于分层存储。
ingest（预处理节点）：在文档写入索引前执行 ingest pipeline，完成字段解析、富化、转换、删除等加工。
coordinating（协调节点）：不承担上述专用职责的节点默认充当协调角色，负责接收客户端请求、把请求分发到相关分片、合并结果并返回。
ml、transform、remote_cluster_client 等：分别承担机器学习、转换任务和跨集群访问，属于按需启用的扩展角色。

一个节点可以同时承担多个角色，但生产环境通常建议把 master 与 data 分离，避免数据节点的负载波动影响选主稳定性。协调节点可以由专用节点承担，也可以由 data 节点兼任，取决于查询并发和网络开销。

二、选主机制与集群状态管理

选主只在 master-eligible 节点之间进行。集群启动或主节点失联时，候选节点发起投票，获得多数派（quorum）支持的节点成为主节点。quorum 的计算方式是 ⌊n/2⌋ + 1，其中 n 是参与投票的 master-eligible 节点数。例如 3 个候选节点需要 2 票，5 个需要 3 票。这个机制保证同一时刻最多只有一个主节点，避免脑裂。

主节点维护的集群状态包含索引元数据、分片分配表、节点列表、模板、ILM 策略等。每次状态变更都会通过 cluster.publish.timeout（默认 30 秒）向所有节点发布。如果某个节点长时间无法确认新状态，主节点会将其移除，触发分片重新分配。因此，master 节点的稳定性直接决定元数据操作的连续性。

生产环境建议配置 3 个专用 master 候选节点，并设置 discovery.seed_hosts 与 cluster.initial_master_nodes（首次启动时）。专用 master 节点不承担 data 和 ingest 职责，避免因数据写入或查询压力导致心跳超时。

三、角色划分对高可用与容量的影响

角色划分不是简单的“功能拆分”，它直接决定了故障域和容量扩展方式。以下从三个维度展开。

1. 高可用维度。master 节点故障时，集群会在 quorum 支持下重新选主，期间元数据写入（如创建索引、修改映射）会短暂阻塞，但已有数据的读写通常不受影响。data 节点故障时，副本分片会被提升为主分片，集群自动重新分配，前提是副本数足够。coordinating 节点故障时，客户端需要切换到其他节点，建议客户端配置多个节点地址并启用 sniffing。ingest 节点故障时，写入请求会失败或降级，需要评估是否把 pipeline 逻辑前移到客户端或使用其他节点兼任。

2. 容量维度。data 节点是存储和查询吞吐的主要承载者，其数量、磁盘类型、JVM 堆大小和分片数量共同决定容量上限。coordinating 节点的容量体现在并发连接数和请求扇出能力上，高并发查询场景建议独立部署。ingest 节点的容量取决于 pipeline 的复杂度和文档吞吐，复杂 pipeline 会消耗大量 CPU。master 节点数量少，但对稳定性和网络延迟敏感，不建议与高负载角色混部。

3. 扩展维度。横向扩展 data 节点可以线性提升存储和查询能力，但分片数量也会增加，进而增加 master 管理集群状态的负担。因此，分片策略需要与 data 节点数量协同规划。coordinating 节点可以按并发需求独立扩展，ingest 节点可以按写入吞吐独立扩展。这种“按角色扩展”的能力，正是角色分离带来的容量工程优势。

四、配置示例与观察要点

以下是一个 3 master + 3 data + 2 coordinating 的示例配置片段，仅用于说明角色声明方式：

# master 节点
node.roles: [ master ]
node.name: master-1

# data 节点
node.roles: [ data_hot, data_content ]
node.name: data-1

# coordinating 节点
node.roles: [ ]
node.name: coord-1

# ingest 节点（可与 data 合并）
node.roles: [ ingest, data_hot ]
node.name: ingest-1

配置完成后，可以通过以下命令观察角色分布和集群状态：

GET _cat/nodes?v&h=name,node.role,master,heap.percent,disk.used_percent
GET _cluster/health?pretty
GET _cat/shards?v

判断依据：_cat/nodes 中 node.role 列应显示 m、d、i、- 等标记，确认角色与规划一致；_cluster/health 的 status 应为 green 或 yellow，number_of_pending_tasks 应接近 0；_cat/shards 中不应有长期处于 INITIALIZING 或 RELOCATING 的分片。如果 master 节点频繁切换或 pending tasks 持续增长，说明集群状态发布存在瓶颈，需要检查 master 节点负载和网络。

角色分离的收益在集群规模超过 10 个节点后尤为明显。小规模集群可以合并角色以节省资源，但必须接受故障域重叠带来的风险。

不要把 master 候选节点与高负载 data 节点混部。数据写入高峰可能导致 master 心跳超时，触发不必要的选主，进而造成元数据操作中断和分片重新分配。

总结来看，Elasticsearch 的角色划分是一套“职责—故障域—容量”三位一体的设计。master 负责决策与状态，data 负责存储与计算，ingest 负责加工，coordinating 负责转发。理解每个角色的边界和失效影响，才能在规划集群时做出合理的节点数量、角色组合和扩展策略，从而在高可用与容量之间取得平衡。