ElasticSearch创建文档以及索引文档的详细流程

        当我们发起一个查询请求之后，ES是怎么处理这个请求然后返回数据的呢？今天就来详细说一下。

首先看一下整体结构：

 

        在集群模式下一个索引有多个分片，在上图中有三个节点(一个主节点两个从节点)，一个索引被分为两个分片(P0、P1)，每个主分片有两个副本分片(R0，R1)，每个主分片底层都是对应一个Lucene Index(Lucenne索引在前面文章已经解释过，可以往回翻翻)，Lucene 索引由多个Segment组成(就是段文件)，每个段存储的就是文档了。

 当我们想要添加一个文档的流程是怎样的呢？

        首先ES在接受到这个请求之后，会通过路由策略来确定需要把文档存储在哪一个shard中去，然后节点接受到请求后就会交由底层的Lucene来处理了。

        Lucene Index会准备待索引的原文档，然后对原文档进行分词处理，形成一系列的term(词条)，然后索引组件对文档和term处理，形成字典和倒排表。这样一个文档基本就被创建好了。

如果是搜索文档的话又是怎样处理的呢？

        Lucene首先会对语句进行分词处理，形成一系列的term。然后根据倒排索引表查找出包含term的文档，并进行合并形成返回结果。最后对查询语句与各个文档的相关性进行评分，最后按分的高低顺序返回结果。

 

 ElasticSearch语法分析器：

        我们在进行搜索的时候，ES是怎么进行分词的？分析过程是：

1. 将文本分成适合倒排索引的独立词条
2. 将词条统一化为标准格式提高他们的可搜索性。

完成上面的功能主要靠三个东西：

• 字符过滤器：字符串按顺序一个个通过字符过滤器，主要是为了处理一些特殊字符，比如说将&转为and。
• 分词器：分词器将字符串分为单个的词条。
• Token过滤器：将分词器分析出来的词条挨个处理，可能会改变词条(大小写转换)，删除无用的词条处理等等...

ES写入文档的详细流程： 

1.当用户发起请求后，首先请求会来到master节点，然后通过文档的id来计算对应的分片，然后再发由相应的节点来处理。

2.当分片所在节点接收到请求后，会把请求先写入Memory Buffer(这个时候数据还没到segment，还搜不到这个文档)。然后每隔1s写入倒File Cache。这个过程叫Refresh。

3.Refresh过程：默认是每隔1s将Memory Buffer的数据写入到File Cache。Segment是存储在文件系统的缓存中的。所以此时文档是可以被搜到的了。refresh后文档存储在文件系统缓存中，这样就避免了性能IO又可以被搜到，refresh默认一秒，为了提高性能可以稍微延长这个时间间隔，比如5s，所以es是准实时，达不到真正的实时。

4.为了防止数据丢失，ES通过Translog来保证数据不会丢失。就是在接收到请求后，数据同时也会写入translog中，当Filesystem Cache中的数据写入到磁盘中之后，这里面的数据才会被清除。这个过程叫flush。

5.文档在文件系统缓存中可能会有意外情况导致文档丢失，需要将文档写入磁盘，将文档从文件缓存系统写入磁盘的过程就叫flush，写入磁盘后translog就会被清空。

flush过程如下：

（1）缓冲区的文档都被写入到一个新的段，然后缓冲区会被清空。

（2）一个commit point被写入硬盘。

（3）文件系统缓存通过fsync被刷新。

（4）老的translog被删除。

 

merge段

每个文档到FileCache都会创建一个新的段，段太多了怎么办？merge过程：

前面说过，在Lucene Index中每次刷新都会产生一个新的段，那么段会越来越多。每一个段都会文件句柄、内存和CPU运行周期，所以段越多那么搜索也会越慢。所以ES会在后台通过Merge Segment来解决这个问题。

当索引的时候Refresh操作会创建一个新的段并且将段打开以供搜索使用。这时候后台的合并进程选择一部分大小相似的段，然后将它合并到更大的段当中，这并不会中断索引和搜索。当合并结束之后，老的段就会被删除：新的段(指合并之后的段)就会被刷新到磁盘，新的段被打开用来搜索，老的段被删除。

注意：合并大的段需要消耗大量的i/o和CPU资源，如果仍其发展会影响搜索性能。ES默认情况下会对合并流程进行资源控制，所以搜索仍然有足够的资源很好的执行。

分布式的写入流程 

在ES中一般一个索引都会被设置为多个shard，通过路由规则将数据分为多个数据子集，每个数据子集提供独立的索引和搜索功能。在写入文档的时候也会根据路由规则(默认通过id)，将文档发给特定的shard进行处理，这样就实现了分布式。

通过前面介绍我们知道了，当数据写入之后一般不会立即写入磁盘而是在File Cache的Lucene Index中，这时候数据还没有写入磁盘中，那么有个问题就是这时候机器宕机内存中的数据就会丢失。这时候如何保证？我们前面也就知道是通过trans log。

• 在每个shard中，写入就被分为两步，就是先写Lucene 在写translog。
• 意思就是写入请求到达shard后，先写Lucene文件，再写translog文件，然后刷新translog到磁盘上，磁盘写入成功之后请求返回给用户。
• 这里为什么会先写lucene文件再写translog文件？原因可能就是Lucen的内存写入会有很复杂的逻辑容易失败，比如超时分词等，为了避免translog中有大量的无效记录，所以就放在前面了。写入Lucene内存后并不是马上就可以被搜索到了，需要refresh把内存中的对象转换为segment后，才可以被搜索到。
• 每隔一段较长的时间，Lucene会把内存中的新Segment刷到磁盘，然后索引文件就把持久化了，translog就没用了，就会被删掉。

更新文档

ES的不支持部分字段的更新，更新都是将整个文档更新，流程如下：

• 收到更新请求后会先从Segment或者translog中读取出完整的文档，记录版本号为V1。
• 然后将请求中的部分要更新的字段和读取出来的文档组合成新的完整的文档，同时更新内存中的Version Map。
• 然后再从version Map中读取该id的最大版本号V2，如果version map中没有，则从segment或者translog中读取一下，这里基本都会从versionMap中读取出来。
• 检查版本是否冲突，如果冲突了就会回退重新执行，如果不冲突就会执行新的add请求。
• 然后将文档doc写入到Lucene中吗，回删除相同id的文档，然后再将这个文档写入进去。
• 释放锁

 

读取文档流程

        搜索一般都是分两阶段的，首先是匹配文档id，第二步是在根据文档id查找对应的文档id，有点类似mysql的索引回表过程。

1.在初始化查询阶段，查询会广播到索引中的每一个分片拷贝。每个分片在本地执行搜索并构建一个匹配文档的大小为from+size的优先级队列。

2.每个分片返回各自的优先级队列中 所有文档的id和排序值 给协调节点，它合并这些值到自己的优先级队列中来产生一个全局排序后的结果列表。

3.接下来协调节点辨别出那些文档需要被取回并且向相关的分片提交多个GET请求，每个分片加载文档一旦所有文档都被取回，协调节点返回结果给客户端。

        我们知道在Es集群中一般一个索引会被分为多个shard，每个shard在不同的node中，而且每个shard一般还会有副本，增加数据的可靠性。那么在查询的时候会从主节点或者副本节点任意选一个来进行查询。在处理一个查询请求的时候首先需要查询所有的shard(同一个shard的primary和replica任选一个即可)。每一个shrad都是一个独立的搜索引擎，然后返回最匹配的TOP10的结果。然后返回给协调节点，协调节点收集所有的shard的返回结果，然后通过优先级队列二次排序，选择top10的结果，然后再通过id去取完整的文档，然后返回给用户。

        上面所说的先根据查询请求取找到合适的id，然后在通过id去取完成的文档这中两阶段的查询在ES中称为query_then_fetch，还有一种一阶段就返回完整doc的称为query_and_fetch，但是一般一阶段就返回文档的适用于只需查询一个shard的请求。