Elasticsearch从入门到进阶——分布式特性
目录
1 Elasticsearch分布式架构
1.1 整体结构与组件关系
1.1.1 集群角色
1.1.2 关于Lucene库的优化
1.2 分布式的特性
1.2.1 高性能
1.2.2 高扩展性
1.2.3 高可用性
2 写入流程
2.1 分片路由
2.2 整体流程
2.3 Lucene写入的原理
3 搜索流程
3.1 Query Phase
3.2 Fetch Phase
4 删除流程
Elasticsearch从入门到进阶——搜索优化原理
https://blog.csdn.net/sniper_fandc/article/details/153831744?fromshare=blogdetail&sharetype=blogdetail&sharerId=153831744&sharerefer=PC&sharesource=sniper_fandc&sharefrom=from_link
上篇文章我们已经对搜索引擎进行了优化，使其的搜索能够加速。但是仅是单机难以应对当下的数据环境，因此本文将来讲讲为了分布式环境集成搜索引擎，Elasticsearch有哪些处理手段：
1 Elasticsearch分布式架构
1.1 整体结构与组件关系
关于一个Segment段，记录了四种数据结构：倒排索引、正排索引、词条索引（FST构建的词的树形索引用来加速搜索）、文档字段（针对某些需要排序的字段单独存储），这是索引的最小的存储单元。
1.1.1 集群角色
Master Node：主节点，管理集群状态、索引分片信息等。
Data Node：数据节点，存储分片数据，负责数据的读/写。
Coordinate Node：协调节点，转发请求（路由的功能），聚合搜索结果并返回响应。
注意：一个节点可能同时具有多个身份，比如一个Node可能既是主节点，又是数据节点。
1.1.2 关于Lucene库的优化
（1）索引不变性
由于Segment段包含众多索引的数据结构，因此如果向同一个Segment新增索引，就会引起多种数据结构的改变，在并发读写的场景下存在很大的性能问题。
因此索引存在一个规则约束，索引一旦生成写入到磁盘中，不再变化。如果还有新的文档要写入，就生成新的Segment。
在这种情况下，旧Segment负责读，新Segment负责写，同时保证索引的读写性能。
（2）并发读
如何查找文档在哪个Segment？Lucene采用并发读的方式，并发读取多个Segment来找到需要的文档。
（3）Segment merging段合并
由于索引不变性，Segment一定会越来越多，那么文件句柄最终会被耗尽，并且也会为并发读多个Segment带来压力。解决办法：定期合并小的Segment为大的Segment。
1.2 分布式的特性
1.2.1 高性能
（1）索引分类
如果一个索引上存储所有类型的数据，那么所有的读写请求都必须请求一个Lucene库的一个Segment，这势必会造成该库的负载过高，并且多方读写请求竞争同一个数据，也会造成性能瓶颈（抢不到数据的必须阻塞等待）。
解决方法：索引分类，每类索引具有不同的名称，负责存储不同类型的数据，每类索引存储在不同的Lucene库。比如有新闻和娱乐两类文档，那么新闻文档存储索引_news，该索引存储在Lucene库1；娱乐文档存储在索引_play，该索引存储在Lucene库2。
业务数据的分类就会让不同读写请求不再竞争同一个Lucene库的同一个索引，有点类似于数据库的分库分表的作用。
（2）分片Shard
同一个索引的数据依然可能过多，仍然存在性能瓶颈。
解决方法：数据分片Shard，将索引进行分片，每份索引是一个Shard分片，每个Shard分片本质是一个Lucene库。
1.2.2 高扩展性
分片数量增多，如果多个分片都在同一个节点上，就会导致单机负载过高。
解决方法：扩展集群，将分片分布在不同的节点上，将读写请求负载到数据对应的分片所在的节点。
1.2.3 高可用性
（1）Master节点选举
节点身份在集群启动时就由配置文件进行定义，而Elasticsearch规定，只有候选主节点才能有主节点的选举权和被选举权，其它节点（数据节点、协调节点）没有主节点的选举和被选举权。
候选主节点的身份通过配置文件定义：
node.master: true选举规则：候选主节点的节点ID值最小的优先成为主节点。
选举流程：节点的后台进程会不断Ping其它节点来实时传递节点的健康状况，候选主节点会通过节点之间的通信收集当前主节点和候选主节点列表两个数据。集群启动/主节点失效时，候选主节点根据当前主节点是否健康来进行选择，如果当前主节点为空（说明主节点异常），此时根据候选主节点列表来进行主节点选举：节点自身ID是最小的（默认成为主节点），等待其它候选主节点的Join请求加入集群；节点自身ID不是最小的，向主节点发送Join请求来加入集群。
避免脑裂：为了避免脑裂（集群中有多个主节点造成集群分裂），候选主节点要成为主节点，必须收到配置文件设置的投票数（一般设置为半数），如果候选主节点收到Join请求的数量超过minimum_master_nodes（未超过超时时间），就能成为主节点；否则就竞选失败（说明此时节点与其它节点的通信存在网络延迟等故障），该分区内的节点进入不可用状态，待故障恢复后加入集群，从而避免了脑裂。
discovery.zen.minimum_master_nodes: (候选主节点总数 / 2) + 1（2）分片副本
当一个节点挂了，那么该节点上所有的数据分片都会消失，此时对于高可用性非常不友好。
解决方法：对分片进行复制，即一个分片存在主分片（Primary Shard）和副本分片（Replica Shard）。主分片提供写数据功能，副本分片提供读数据功能，当主分片写入数据后，需要同步给副本分片。
注意：如果主分片和副本分片存在同一个节点上，那实际上仍然不能保证高可用性，因此主分片和副本分片应该保存在不同节点上。
（3）故障转移
如果主分片的节点挂了，由于其它节点存在副本分片，因此该副本分片就会提升为主分片，承担主分片原有功能。
2 写入流程
2.1 分片路由
如何确定一个文档应该存储到哪个分片中？主要是通过hash函数+除余的方式确定：
shard = hash(routing) % number_of_primary_shardsrouting默认是文档id，也可自定义值。通过为routing进行哈希函数的运算，得到的值再对主分片数量（创建索引时就应该指定好）number_of_primary_shards进行除余运算，得到的余数就是分片的位置标识。
2.2 整体流程
当需要写文档时，请求会先发送到协调节点，协调节点根据分片路由计算文档应该写入到哪个分片，并把文档发送到那个分片。
主分片得到文档后，执行写入操作，将文档解析为词条索引、倒排索引、正排索引、文档字段并存储到Lucene库中。
主分片执行写入操作后将索引同步给副本分片，来确保数据一致性。
之后，主分片所在的数据节点就会返回ACK响应给协调节点，协调节点就知道写入操作执行完了，返回给用户。
2.3 Lucene写入的原理
上述写入操作实际上并不是直接将文档写入到磁盘上的Segment，具体流程如下：
（1）文档首先会被写入到内存缓冲区，同时记录事务日志translog文件（记录每一次操作）。但此时文档还不可被搜索到。
（2）内存缓冲区的文档会被定期refresh到文件系统缓冲区的新Segment，但此时还没有写入到磁盘的Segment。同时，清空内存缓冲区的文档。此时文档可以被搜索到。这步操作的目的是为了平衡内存、磁盘之间的I/O速率，既可以使文档被搜索，又能避免磁盘读写速度太慢。
（3）每隔一段时间，根据事务日志translog文件记录的操作，将文档flush到磁盘中的新Segment，同时清除务日志translog。
3 搜索流程
搜索流程分为两个阶段：Query Phase阶段（查询倒排索引）和Fetch Phase阶段（获取正排索引的数据）：
3.1 Query Phase
Query Phase阶段首先由协调节点接受请求，协调节点内部记录了索引名称和分片之间的对应关系，根据分片路由将请求转发到对应分片上。
分片根据关键词查询倒排索引获取文档id、查询文档字段用来排序，将排序后的文档id返回给协调节点。
3.2 Fetch Phase
协调节点收到上一阶段返回的排序后的文档id列表进行聚合操作，去除重复、无关的文档id。再根据文档id去各文档所在分片上查询正排索引，得到文档内容并返回。
协调节点将文档内容返回给用户。
4 删除流程
由于索引的不变性，因此不能随意的把不需要的文档删除。既然这样，那该如何删除文档呢？
解决方法：对segment用一个.del文件关联。当发送删除请求时，该文档未被真正删除，而是在.del文件中标记为已删除。此文档可能仍然能被搜索到，但会从结果中过滤掉。当segment merg ing时，合并过程中再进行真正的删除操作。
以上架构和流程就是Elasticsearch关于分布式和Lucene库的核心设计。