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的时候，以主分片作为权威数据，即先写主分片，成功后再写副分片，恢复阶段以主分片为准），分担集群压力，但是多副本也带来了数据一致性的问题。

在创建索引时，要根据自己的数据量和增长量确定分片数（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.集群启动流程

4.1选举主节点

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

4.2 选举集群元数据信息

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

4.3 allocation过程

分配主分片

未完待续.......