分片（Shard）

elasticsearch作为一个可以支持PB级数据的搜索引擎中间件，单台节点的必然是不可以满足服务的高可用以及数据存储的。
如何让数据分布到所有节点呢，elasticsearh引入分片(Shard)解决该问题。

• 分片是es支持PB级数据的基石，分片存储了部分数据，可以分布于任意节点
• 分片在创建索引时设置，一旦设置不可在更改
• 创建索引时默认分配一个分片（7.X版本），6.X版本默认5个

副本（replicas）

分片有主分片和副本分片，副本分片实现数据的高可用，因为分片只存储部分数据，如果其中一个分片节点挂了，那么该分片的数据必然就会在集群中缺失，无法被检索，那么副本分片可以被分配到其他节点，这样即使主分片挂了，副本依然可以保证数据的完整性。

• 副本分片的数据由主分片同步，可以有多个副本分片
• 副本数量在创建索引后可以修改

Master Node

• master节点通过集群所有节点选举产生
• 具有被选举为master节点资格的节点也叫Master-eligible 节点
• 每个节点默认为master节点，表示有资格竞选master节点
• master节点负责管理集群，保存集群状态等

• 设置方式：

  
  

Data Node

数据节点管理包含您已建立索引的文档的分片。数据节点处理与数据相关的操作，例如CRUD，搜索和聚合。这些操作是I / O，内存和CPU密集型的。监视这些资源并在过载时添加更多数据节点非常重要。

• 节点默认为数据节点
• 每个数据节点主要维护一下内容：
  • 分配给该节点的每个分片的分片数据
  • 分配给该节点的每个分片相对应的索引元数据

  • 集群范围的元数据，例如设置和索引模板。

    
    

Coordination Node

处理请求的节点即为 coordinating节点,该节点为所有节点的默认角色,不能取消
路由请求到正确的节点处理,比如创建索引的请求到 master节点
如果要添加专门的处理请求的节点，不做其他角色，可以这样设置：

集群状态

• green：健康状态,指所有主副分片都正常分配
• yellow：指所有主分片都正常分配,但是有副本分片未正常分配
• red：有主分片未分配

单节点集群

创建个索引

如果不做任何设置，默认分配一个主分片，一个副本，这里要注意的是我现在的使用的是7.9版本，默认分配一个分片，在6.X版本中默认分配5个分片

当我们在加入一个节点，然后创建一个索引，如果
分片0和副本0就会自然的被分配到不同的节点，保证服务高可用

故障转移

假设现在有三个节点，为索引分配3个主分片一个副本
node1是master节点
有p0、p1、p2三个主分片，R0、R1、R2三个副本

假设node1下线，那么集群会重新选举出一个master，然后将R0提升为主分片，然后重新分配R1、R0

文档存储流程

当我们发起一个保存文档的请求时，集群是如何把文档存储到对应的节点的呢
首先，需要一个文档的分片算法
es通过如下的公式计算文档对应的分片
shard = hash(routing)%number_of_primary_shards

• hash算法保证可以将数据均匀地分散在分片中
• routing是一个关键参数,默认是文档id,也可以自行指定
• number_of_primary_shards是主分片数该算法与主分片数相关,这也是分片数一旦确定后便不能更改的原因
  假如node3接收到了创建文档的请求

2. node3通过算法计算出应该存储到分片p1，查询cluster state后确认主分片p1在node2上，然后转发创建文档请求到node2
   

3. P1接收请求并创建文档，然后将请求同样发送到副本R1
   

4. R1接收请求并创建，通知P1成功
   

5. P1再通知node3
   

6. node3通知Client