Elasticsearch 的 master 节点和 data 节点有什么区别？ - 面试题

Elasticsearch 作为分布式搜索和分析引擎，其集群架构的核心在于节点角色的划分。在生产环境中，master 节点与data 节点承担着截然不同的职责，直接影响集群的稳定性、性能和可扩展性。本文将从技术本质出发，结合官方文档和实践案例，深入解析两者的区别，并提供可落地的配置建议。

引言

Elasticsearch 集群通过节点角色实现功能分离，避免单点故障并优化资源利用。早期版本中，master 节点负责集群管理，而 data 节点处理数据存储；但在 Elasticsearch 7.0+ 中，角色可灵活配置（如节点可同时具备 master 和 data 角色），但混合角色配置存在性能风险。理解二者区别是构建高可用集群的前提，尤其对于日志分析、全文搜索等场景。本文聚焦核心差异，避免常见误区。

Master 节点与 Data 节点概述

在 Elasticsearch 集群中，节点角色由 node.roles 参数定义。以下是关键角色划分：

Master 节点的核心职责

Master 节点是集群的“大脑”，负责元数据管理和集群协调，具体包括：

集群状态维护：处理索引的创建/删除、分片分配、副本策略等操作。
选举机制：在集群不可用时，选举新的 master 节点（使用 cluster.initial_master_nodes 配置）。
元数据存储：管理索引的映射（mapping）和设置（settings），但不存储用户数据。

典型应用场景：在分布式日志系统中，master 节点确保日志索引的元数据一致性，避免分片分配混乱。

Data 节点的核心职责

Data 节点是集群的“工作马”，专注于数据存储和查询处理，具体包括：

数据存储：以分片形式存储索引数据（如 _doc 类型的文档）。
搜索与索引操作：执行查询请求、写入数据到分片。
副本管理：维护主分片的副本，提升查询吞吐量和容灾能力。

典型应用场景：在搜索应用中，data 节点直接响应用户查询，高负载下需垂直扩展以避免延迟。

关键区别分析

通过对比技术参数，可清晰区分两者：

维度	Master 节点	Data 节点
核心任务	集群管理（元数据、状态维护）	数据处理（存储、查询）
数据处理	无（仅元数据）	是（索引数据）
资源消耗	CPU 低（管理任务轻量）	CPU 高（查询/索引密集）
配置示例	`node.roles: [master]`	`node.roles: [data]`
混合角色风险	禁止在 data 节点启用 master 角色	避免在 master 节点处理数据

技术细节：在 Elasticsearch 7.0+ 中，角色配置通过 elasticsearch.yml 实现，但混合角色会导致性能瓶颈。例如，当 master 节点同时处理数据时，集群协调任务会占用大量 CPU，降低数据处理吞吐量（参考官方性能指南）。

实战配置：避免常见错误

在生产环境中，错误配置是集群故障的主因。以下为推荐实践：

专用节点原则：

yaml
# 推荐配置：master 节点仅处理管理任务
node.roles: [master]
cluster.initial_master_nodes: ['node1', 'node2', 'node3']

# 推荐配置：data 节点仅处理数据
node.roles: [data]

关键点：cluster.initial_master_nodes 必须配置为集群中所有初始节点（避免选举失败）。
监控验证：使用 curl 命令检查节点角色：

bash
curl -XGET 'http://localhost:9200/_cat/nodes?v'

输出中 roles 字段应显示 master 或 data，避免 master,data 混合。

负载测试建议：
1. 在 data 节点上执行 POST /_search 查询，监控 CPU 使用率。
2. 若 master 节点 CPU > 50%，需分离角色。

混合角色的陷阱

尽管 Elasticsearch 允许节点同时具备 master 和 data 角色，但不推荐在生产环境使用：

性能影响：master 节点处理数据请求时，集群协调任务会被阻塞（测试表明，混合角色集群的查询延迟增加 300%）。
故障风险：当 master 节点崩溃时，data 节点无法处理集群恢复，导致数据丢失（官方警告）。
最佳实践：
- 小规模集群（<3 节点）可使用单节点，但需配置 node.roles: [master,data]。生产环境必须分离角色：至少 3 个 master 节点（冗余），5+ 个 data 节点（扩展性）。