5、Elasticsearch读写流程

一、写流程

1、新增流程描述

Elasticsearch中每个index由多个shard组成，默认是5个，每个shard分布在不同的机器上。shard分为主分片和副本分片，在文档写入时，会根据_routing来计算（OperationRouting类）得出文档要写入哪个分片。这里的写入请求只会写主分片，当主分片写入成功后，会同时把写入请求发送给所有的副本分片，当副本分片写入成功后，会传回返回信息给主分片，主分片得到所有副本分片的返回信息后，再返回给客户端。

在写入时，我们可以在Request自己指定_routing，也可以在Mapping指定文档中的Field值作为_routing。如果没有指定_routing，则会把_id作为_routing进行计算。由于写入时，具有相同_routing的文档一定会分配在同一个分片上，所以如果是自定义的_routing，在查询时，一定要指定_routing进行查询，否则是查询不到文档的。这并不是局限性，恰恰相反，指定_routing的查询，性能上会好很多，因为指定_routing意味着直接去存储数据的shard上搜索，而不会搜索所有shard。

Elasticsearch文档写入主要是写主分片和写副本分片。所以副本分片的个数就直接决定了写入的性能。合理配置副本数，在性能和安全之间取得平衡。

Lucene中索引数据只有在生成segment文件之后才会被查询到，Elasticsearch则是周期性（默认1秒）生成一个segment文件，生成的segment是允许被查询的，这样也就实现了near-real-time。

ElasticSearch 有一个后台进程专门负责 segment 的合并，定期执行 merge 操作，将多个小 segment 文件合并成一个 segment，在合并时被标识为 deleted 的 doc（或被更新文档的旧版本）不会被写入到新的 segment 中。合并完成后，然后将新的 segment 文件 flush 写入磁盘；然后创建一个新的 commit point 文件，标识所有新的 segment 文件，并排除掉旧的 segement 和已经被合并的小 segment；然后打开新 segment 文件用于搜索使用，等所有的检索请求都从小的 segment 转到 大 segment 上以后，删除旧的 segment 文件，这时候，索引里 segment 数量就下降了。

2、新增流程图

3、update流程

1、接受update请求后，首先通过id在Segments或TransLog中取出要修改的文档内容，记录版本号为V1。

2、将版本号为V1的全部文档内容与要修改的文档内容（修改部分字段内容）合并，同时更新内存中的VersionMap。自此修改后的新文档已经生成，接下来就是index请求，把修改后的文档索引。

3、加锁

4、再次从versionMap中读取该id的最大版本号V2，如果versionMap中没有，则从Segment或者TransLog中读取。

5、检查版本是否冲突，如果V1==V2，则说明修改的最高版本号的文档，则进入下一步。如果V1 < V2，说明本次修改并非修改的最高版本号的文档，修改失败。返回第一步重新执行。

6、将版本号递增为V3（V2+1）。然后把文档写入到Lucene中，Lucene会先删除掉原来id的文档，然后把修改后的新文档增加进去。然后更新VersionMap中的版本号为V3。

7、释放锁，更新结束

4、写流程总结

1、ES在集群模式下，有多个 Node （节点）组成。每个节点就是 ES 的Instance (实例)。

2、每个节点上会有多个 shard （分片）， P1 P2 是主分片, R1 R2 是副本分片

3、每个分片上对应着就是一个 Lucene Index（底层索引文件）

4、Lucene Index 是一个统称由多个 Segment （段文件，就是倒排索引）组成。每个段文件存储着就是Doc文档。commit point记录了所有 segments 的信息。

5、ElasticSearch 有一个后台进程专门负责 segment 的合并，定期执行 merge 小的 segment 转到 大 segment 上以后，然后删除旧的 segment 文件。

二、读流程

2.1、普通查询

2.2、聚合查询