Elastic Search源码学习笔记

Elastic Search是实时分布式搜索分析引擎,内部使用Lucene做索引和搜索(是处理文本数据的库,提供索引和执行搜索等接口,不包含分布式服务)。

1.索引结构

ES通过_index、_type和_id 唯一标识一个文档(一般都是JSON),一个_index中可以创建多个_type,实际应用中,一个索引只存在一个_type,因为删除_type后并不会释放空间,在ES 6.X版本中,已经限制一个索引只能创建一个_type,未来的7.X版本将删除_type的概念。

2.分片(Shard)

数据分片提高了水平扩展能力,分布式存储还提供了多个副本,放置到不同的机器上,提供备份功能,同时多个副本可以使read操作并发执行(数据update的时候,以主分片作为权威数据,即先写主分片,成功后再写副分片,恢复阶段以主分片为准),分担集群压力,但是多副本也带来了数据一致性的问题。

Elastic Search源码学习笔记_第1张图片

在创建索引时,要根据自己的数据量和增长量确定分片数(5.X版本之前不支持分片数修改,5.X版本及以后支持有限的修改),副分片数可以随时修改。使用非常大的分片,因为这会对群集从故障中恢复的能力产生负面影响, ES对分片的大小没有固定的限制,实际项目中不应该向单个索引持续写数据,直到它的分片无比巨大,巨大的索引会导致数据老化后难以删除,以_id为单位删除数不会立即释放空间,删除的数据只会在Lucene分段合并时才做到磁盘回收,而且分段合并会导致很高的I/O压力,因此一般一个分片数据量不超过50G。
当索引的分片不够用或者每个索引数据很小时,可以考虑创建新索引或者使用splitAPI来拆分或shrinkAPI缩减索引(6.1版本开始支持),但是更多的采用周期性的创建索引,假如有一个log-biz-idx的索引,可以将它命名为log-biz-idx-20190206的索引,创建一个log-biz-idx的索引别名名字,关联log-biz-idx-*开头的所有索引,这样业务方访问的索引名字仍然是log-biz-idx,实现了对业务方的透明。

3.集群内部结构

ES是主从模式设计

3.1 主节点(Master node)

主节点负责集群的相关操作,管理集群变更,且全局唯一,一般采用主节点和数据节点分离的部署架构。为防止数据丢失,每个主节点要知道哪些从节点有资格成为主节点的数量。

3.2 数据节点(Data node)

负责保存数据,执行数据相关的操作,一般情况下(特殊除外),数据读写只和数据节点交互,不会和主节点打交道。

3.3 预处理节点(ingest node,5.0版本引入)

在索引写入数据之前,通过事先定义好的processors和pipeline,对数据进行转换、富化。processors和pipeline拦截bulk和index请求,在应用相关操作后,将文档传回给index或bulk API。

3.4 协调节点(Coordinating node)

协调节点将请求转发给Data node,每个Data node在本地执行请求,并返回给协调节点,协调节点将每个Data node的结果收集、合并甚至排序为单个全局结果,因此协调节点需要较多的CPU和内存资源。

3.5集群状态元数据

集群状态元数据是全局信息,主要包括内容路由信息(即哪个分片位于哪个节点的信息)、配置信息等。主节点维护集群状态数据,主节点接收Data node的更新,并将更新广播到其他节点(采用增量 + 压缩的方式)。

3.6 集群扩容

当扩容集群添加节点时,分片会均衡地分配到集群的各个节点上,从而对索引和搜索过程进行负载均衡,这些都由系统自动完成。分片分配过程还会保证不把主分片和副分片分配到同一个节点上,避免单节点故障引起数据丢失。

4.集群启动流程

Elastic Search源码学习笔记_第2张图片

4.1选举主节点

ES的选主算法基于Bully算法,主要算法是对节点ID进行排序,取ID值最大的节点作为Master,然后再把最新的机器元数据复制到Master节点上。
基于节点ID的排序算法约定的三个条件
a.参选人数过半;
b.得票数需过半;
c.当探测到节点离开时间时,必须判断当前节点数是否过半,否则放弃Master身份,重新加入集群。这样防止了脑裂。

4.2 选举集群元数据信息

被选举出的Master第一个任务就是选举元信息,让各个节点把各自的元信息发过来,根据版本好确定最新的元信息,然后将最新的元数据信息再广播到所有节点。

4.3 allocation过程

分配主分片

未完待续.......

你可能感兴趣的:(Elastic Search源码学习笔记)