主节点（或候选主节点）

主节点负责创建索引、删除索引、分配分片、追踪集群中的节点状态等工作， 主节点负荷相对较轻， 客户端请求可以直接发往任何节点， 由对应节点负责分发和返回处理结果。

一个节点启动之后， 采用 Zen Discovery机制去寻找集群中的其他节点， 并与之建立连接， 集群会从候选主节点中选举出一个主节点， 并且一个集群只能选举一个主节点， 在某些情况下， 由于网络通信丢包等问题， 一个集群可能会出现多个主节点， 称为“脑裂现象”， 脑裂会存在丢失数据的可能， 因为主节点拥有最高权限， 它决定了什么时候可以创建索引， 分片如何移动等， 如果存在多个主节点， 就会产生冲突， 容易产生数据丢失。要尽量避免这个问题， 可以通过 discovery.zen.minimum_master_nodes 来设置最少可工作的候选主节点个数。 建议设置为（候选主节点/2） + 1 比如三个候选主节点，该配置项为 （3/2）+1 ,来保证集群中有半数以上的候选主节点， 没有足够的master候选节点， 就不会进行master节点选举，减少脑裂的可能。

主节点的参数设置：

1
2

node.master = true
node.data = false

数据节点

数据节点负责数据的存储和CRUD等具体操作，数据节点对机器配置要求比较高、，首先需要有足够的磁盘空间来存储数据，其次数据操作对系统CPU、Memory和IO的性能消耗都很大。通常随着集群的扩大，需要增加更多的数据节点来提高可用性。

数据节点的参数设置：

1
2

node.master = false
node.data = true

客户端节点

客户端节点不做候选主节点， 也不做数据节点的节点，只负责请求的分发、汇总等等，增加客户端节点类型更多是为了负载均衡的处理。

1
2

node.master = false
node.data = false

提取节点（预处理节点）

能执行预处理管道，有自己独立的任务要执行， 在索引数据之前可以先对数据做预处理操作， 不负责数据存储也不负责集群相关的事务。

协调节点

协调节点，是一种角色，而不是真实的Elasticsearch的节点，不能通过配置项来指定哪个节点为协调节点。集群中的任何节点，都可以充当协调节点的角色。当一个节点A收到用户的查询请求后，会把查询子句分发到其它的节点，然后合并各个节点返回的查询结果，最后返回一个完整的数据集给用户。在这个过程中，节点A扮演的就是协调节点的角色。

ES的一次请求非常类似于Map-Reduce操作。在ES中对应的也是两个阶段，称之为scatter-gather。客户端发出一个请求到集群的任意一个节点，这个节点就是所谓的协调节点，它会把请求转发给含有相关数据的节点(scatter阶段)，这些数据节点会在本地执行请求然后把结果返回给协调节点。协调节点将这些结果汇总(reduce)成一个单一的全局结果集(gather阶段) 。

部落节点

在多个集群之间充当联合客户端， 它是一个特殊的客户端 ， 可以连接多个集群，在所有连接的集群上执行搜索和其他操作。 部落节点从所有连接的集群中检索集群状态并将其合并成全局集群状态。 掌握这一信息，就可以对所有集群中的节点执行读写操作，就好像它们是本地的。 请注意，部落节点需要能够连接到每个配置的集群中的每个单个节点。