elasticsearch 集群 分片 副本 脑裂 共识 一致性

Share分片

1. 主分片（Primary Shard）

   • ES中分片是用来解决节点容量上限问题，通过主分片，可以将数据分布到集群的所有节点。

   • 节点和Index关系：

     • 一个节点对一个一个ES实例，即一个ES的java的进程。

     • 一个节点可以有多个Index索引。

     • 一个Index可以有多个Share分片。

     • 一个分片（Share）是一个Lucene Index， （Luncene的Index和ES的Index不是一个概念）。

   • 主分片数量是在索引创建时指定，后续不允许修改，如果修改，需要重建索引。

   • 一个Index中的数据保存在多个分片中（默认为1个），相当于水平分表，一个分片即为一个Luncene实例，本身就是一个完整的创建索引和处理请求能力。文档被存储和索引到分片内，但是应用程序直接与Index交互，不是与分片交互。

2. 副本（Replica Shard），副本作用：

   • 服务高可用：主分片数据只有一份，如果只有主分片并且主分区node挂了，则数据全部丢失。副本存主分片数据，如果不是数据node全挂，数据就不会丢失。因此副本分片不会与主分片分配到同一个节点。

   • 扩展性能：副本分片数据是近实时（near realtime）数据，通过设置合理的副本数量，通过在所有的副本分片上并行搜索，提高搜索性能和吞吐量。

3. 分片设定：

   • 主分片数量是在创建索引时预先设定的，后续无法修改，如果修改在需要重建索引。对于生产环境中的分片设定，需要提前做好规划。

   • 分片数设置过小：

     • 导致后续无法水平扩展节点。

     • 分片的数据量太大，数据在重新分配时耗时。

   • 分片数量设置过大：

     • 影响搜索结果相关性打分和统计结果的准确行。

     • 单个节点过多分片，导致资源浪费，影响性能。

4. 主分片和副本分片关系：

   1. ES会自动再nodes上做分片（Shard）负载。

   2. 一个文档只能存储在一个主分区，但可以存在于多个副本分区。

   3. 主分区和对应的副本分区不能同时存在与同一个节点，所以最低的可用配置是2个节点，互为主备。

通常情况 有几个个节点 就分配几个分片和副本

参考 https://www.jianshu.com/p/45dba6bdb9ec

脑裂 

es脑裂：一个大的es集群分裂成了多个小的集群。
比如有 a b c d 四个es

a b c d 之间选取一个master，比如master是a。
若某时刻 c d 访问不到a ，b能访问到a。
c d之间会重新选举一个master。
这样整个a b c d的es集群就会分裂为a b 和 b c 两个集群。

.解决方法
（1）不要把主节点同时设为数据节点，即node.master和node.data不要同时为true。
  
主节点配置为：

node.master: true
node.data: false
1
2
从节点配置为：

node.master: false
node.data: true
1
2
（2）将节点响应超时discovery.zen.ping_timeout稍稍设置长一些（默认是3秒）。默认情况下， 一个节点会认为， 如果master节点在 3 秒之内没有应答， 那么这个节点就是挂掉了， 而增加这个值， 会增加节点等待响应的时间， 从一定程度上会减少误判。

（3）discovery.zen.minimum_master_nodes的默认值是1，该参数表示， 一个节点需要看到的具有master节点资格的最小数量， 然后才能在集群中做操作，即重新选举主节点。官方的推荐值是(N/2)+1，其中 N 是具有 master资格的节点的数量，即只有超过(N/2)+1个主节点同意，才能重新选举主节点。

 

参考  https://blog.csdn.net/BruceLiu_code/article/details/118359321

 

共识

洛谛19

 

Elasticsearch的选举

 一、bully算法
  经过以下几个步骤
 　　 1.启动节点ping协调器,获取当前集群状态(节点信息,集群名称等),如果协调器没有启动一直到ping通为止
  　　2.无论能ping通,都会拿到对象activeMaster现役master
 　　 3.判断activeMaster的数量,0说明当前集群没有master,1表示当前集群已经选举完毕.
 　　 4.如果为1,当前节点启动Bully算法逻辑结束;如果为0,进入第5步(总会停止在这里)
 　　 5.启动时发现没有现役master,将集群中所有的master节点放到candidate的候选名单中.候选名单大于等于最小master数量,小于最小master数量.
 　　 6.如果candidate中大于等于master最小数量,从其中选举一个id值最小的节点放到activeMaster中,暂定为master,如果小于最小master转回第一步.
 二、master宕机逻辑
  　　在集群中,任意节点的变化,都会导致所有人记录的candidate/activeMaster发生变化
  　　○ activeMaster发生变化(1-0),主节点宕机
  　　重新进行选举
  　　○ candidate发生变化,现役master正常,其他备选有宕机现象;
　　重新判断集群的最小个数(activeMaster+candidate个数>=最小master)

参考 Elasticsearch的选举 - 洛谛19 - 博客园 (cnblogs.com)

 

一致性 

参考 elasticsearch如何保证数据一致性？剖析复制与写入机制 (baidu.com)

参考 【es】es 分布式一致性原理剖析 节点篇_es 一致性协议_九师兄的博客-CSDN博客