es相关总结-CFANZ编程社区

索引分片和lucene关系

一个Es索引包含很多分片，一个分片是一个Lucene的索引，它本身就是一个完整的搜索引擎，可以独立执行建立索引和搜索任务。Lucene索引又由很多分段组成，每个分段都是一个倒排索引。ES每次refresh都会生成一个新的分段，其中包含若干文档的数据，在每个分段内部，文档的不同字段被单独建立索引。每个字段的值由若干词(Term)组成，Term是原文本内容经过分词器处理和语言处理后的最终结果。
在这里插入图片描述

近实时搜索（refresh）

在写操作中，首先被写入到内存缓存中，默认每1秒将in-memory index buffer中的文档生成一个新的段并清空原有in-memory index buffer，新写入的段变为可读状态，但是还没有被完全提交。该新的段首先被写入文件系统缓存，保证段文件可以正常被正常打开和读取，后续再进行刷盘操作。由此可以看到，ES并不是写入文档后马上就可以搜索到，而是一个近实时的搜索（默认1s后）

不完整提交（因为没有刷盘）
refresh资源消耗相对较小，避免每次文档写入fsync导致资源上的瓶颈
默认每1s进行一次refresh，refresh后的段可以被打开，实现近实时搜索

flush

即使通过每秒refresh实现了近实时搜索，但refresh无法保障数据安全，我们仍然需要经常进行完整提交来确保能从失败中恢复。flush就是一次完全提交的过程，一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点。Elasticsearch 在启动或重新打开一个索引的过程中使用这个提交点来判断哪些段隶属于当前分片，保证数据的安全。

为此ES增加了一个 translog ，或者叫事务日志，在每一次对 ES的变更操作除写入内存缓存外还会写入到translog中，translog周期性刷盘，保证变更的持久性。

将translog中所有的段进行全量提交并对translog进行截断的操作叫做flush，flush操作期间会做的事项主要有：

强制refresh，将内存缓冲区所有文档写入一个新的段，写入到文件系统缓存并将旧的内存缓冲区被清空（refresh）
将最新的commit point写入磁盘
将文件系统缓存中的段通过fsync进行刷盘
删除老的translog，启动新translog

什么是translog

translog就是ES的一个事务日志，当发生一个文档变更操作时，文档不仅会写入到内存缓存区也会同样记录到事务日志中，事务日志保证还没有被刷到磁盘的操作的进行持久化。translog持久化后保证即使意外断电或者ES程序重启，ES首先通过磁盘中最后一次提交点恢复已经落盘的段，然后将该提交点之后的变更操作通过translog进行重放，重构内存中的segment。

translog也可以被用来实时CRUD搜索，当我们通过_id进行查询/更新/删除文档时，ES在检索该文档对应的segment时会优先检查translog中最近一次的变更操作，以便获取到最新版本的文档记录。

translog基本流程

一个文档被索引之后，就会被添加到内存缓冲区，并且追加到了translog
默认每秒refresh一次，refresh会清空内存缓存，但是不会清空translog
refresh操作不断发生，更多的文档被添加到内存缓冲区和追加到translog
translog周期性通过fsync进行刷盘，默认5s，可通过参数index.translog.sync_interval、index.translog.durability控制，保证应用重启后先确认最后记录的commit point，commit point之后的变更操作通过落盘的translog进行重构恢复段
默认当translog太大（512MB）时，进行flush操作

merge

每次refresh操作都会生成一个新的segment，随着时间的增长segmengt会越来越多，这就出现一个比较严重的问题是每次search操作必须依次扫描所有的segment，导致查询效率变慢，为了避免该问题es会定期多这个segment进行合并操作。

什么是merge

将refresh产生的多个小segment整合为一个大的segment的操作就叫做merge。同时merge操作会将已经打.del标签的文档从文件系统进行物理删除。merge属于一个后台操作。

在es中每个delete操作其实都是对将要删除的文档打一个.del的标签，同理update操作就是将原文档进行.del打标然后插入新文档，只有merge操作才会将这些已经打标的.del文件真正进行物理删除。

一个大segment的merge操作是很消耗CPU、IO资源的，如果使用不当会影响到本身的serach查询性能。es默认会控制merge进程的资源占用以保证merge期间search具有足够资源。

merge操作相关流程

refresh操作会相应的产生很多小的segment文件，并刷入到文件系统缓存（此时文件系统中既有已经完全commit的segment也有不完全提交仅searchable的segment）
es可以对这些零散的小segment文件进行合并（包含完全提交以及searchalbe的segment）
es会对merge操作后的segment进行一次flush操作，更新磁盘commit point
将merge之后的segment打开保证searchalbe，然后删除merge之前的零散的小segment

集群内部原理

集群节点角色

1. 主节点

主节点负责集群层面的相关操作，管理集群变更。
通过配置node.master:true（默认）是节点具备选举为master的资格，主节点事全局唯一的，将从有资格成为master的节点中进行选举。
为了避免网络分区出现多主的情况，配置discovery.zen.mininum_master_nodes原则是主节点数过半加一。

2. 数据节点

负责保存数据、执行数据相关操作，配置node.data:true（默认）来使一个节点成为数据节点。

3.协调节点

协调节点将请求转发给保存数据的数据节点。每个数据节点在本地执行请求，并将结果返回协调节点。协调节点收集完数据后，将每个数据节点的结果合并成为单个全局结果，对结果收集和排序的过程可能需要CPU和内存资源。

集群状态

从数据完整性的角度划分，集群状态分为三种：

Green，所有的主分片和副分片都正常运行。
Yellow，所有的主分片都运行正常，但不是所有的副分片都正常运行。这意味着存在单点故障的风险。
Red，有主分片没能正常运行。

每个索引也有上述的三种状态，假设丢失一个副分片，该分片所属的索引和整个集群变为Yellow状态，其他索引认为Green。

集群启动流程

在这里插入图片描述

选举主节点

ES的选主算法事基于Bully算法的改进，主要思路是对节点ID排序，取ID最小的节点作为Master，每个节点都运行这个流程。但是会出现选举出的主节点可能不是最新的元数据信息，实际上被分解为两步：先确定唯一的、大家公认的主节点，再想办法把最新的机器元数据复制到选举出的主节点上。
基于节点ID排序的简单选举算法有三个附加约定条件：

参选人数需要过半，达到quorum(多数)后选出了临时的主，为什么是临时的？每个节点运行排序取最小值的算法，结果不一定相同。举个例子，集群中有5台主机，节点ID分别是1、2、3、4、5。当产生网络分区或节点启动速度差异较大时，节点4看到的节点列表是1、2、3、4，选出的节点是2；节点5看到的是2、3、4，选出的是2，结果就不一致了。由此加了第二条限制
得票数过半，某节点被选为主节点，必须判断加入它的节点数过半，才确认Master身份，解决第一个问题。
当探测节点离开事件时，必须判断当前节点数是否过半。如果达不到quorum，则放弃Master身份，重新加入集群。如果不这么做，则设想一下情况：假设5台机器组成的集群产生网络分区，2台一组，3台一组，产生分区前，Master位于2台其中的一个，此时3台中一组的节点会重新选取Master，产生双主，俗称脑裂。