elasticsearch index doc过程概述

文章目录

概述
1.es中的基础概念
2.es中的索引过程
- 2.1 一次index请求的大体流程
- 2.2 为什么是near real time
- 2.3 为什么要有translog
- - 2.3.1 translog的作用
  - 2.3.2 translog的持久化机制
  - 2.3.2 commit产生的时机

概述

这里主要讲讲es index的过程，努力揭示es在index过程中具体做了哪些工作。
从而增加我们对es的了解，以便于更好的使用和优化es。

1.es中的基础概念

es的基础支撑是使用lucene,每个es的索引(index)有多个shard，每个shard都是一个独立的lucene实例
每个lucene实例通过多个segment来管理自己存储的数据，每个segment可一个认为是独立的存储单元，从存储功能上来说类似于mysql中分表中的一张表
每个lucene实例同时引入了一个commit的概念来管理segment,因为segment是要写入磁盘的，如果每产生一个segment都要写入磁盘的话，那么效率会受到影响，所以一般都是多个segment进行一次写磁盘操作，叫做commit，每次commit记录了本次提交的节点的一个快照信息。也就是一个commit check point。这里的每个commit 产生的check point 对应的文件是lucene data存储目录下的segment_N文件，看lucene网上说每个lucene实例中可能有多个segment_N文件(主要是因为有些segment_N文件暂时不能删除，或者使用了自定义的删除策略)
参考这里
只有数据进入一个segment当中才能够被搜索到。

2.es中的索引过程

基于上面的基础知识，我们来梳理一下对于客户端通过http请求过来的一个index操作，对应的在elasticsearch的后端会对应的经历哪些操作

2.1 一次index请求的大体流程

请求的路由:请求可能被发往es集群当中的任意一个节点（此时假设为A）。所有在Elasticsearch集群中的节点都包含：有关哪个分片存在于哪个节点上的元数据。根据一定的规则计算该文档需要被发往哪个shard(主要是根绝文档的id来计算),接收请求的节点将请求路由到对应的主分片所在节点(假设为B)。
请求的处理:当节点B接收到来自节点A的请求时，请求被写入到translog（下面会讲到），并将该文档添加到内存缓冲区。如果请求在主分片上成功，则请求将并行发送到副本分片。只有在所有主分片和副本分片上的translog被持久化(fsync’ed)后，客户端才会收到该请求成功的确认。

2.2 为什么是near real time

在经过上面两步介绍，基本上了解了es处理请求的一个大致的套路
那为什么说es是一个近实时(near real time)的搜索引擎呢，因为通过上面的请求写进es的文档并不能立即被搜索到。正常情况下可能会有一秒钟的延迟，也就是在add之后，最长可能需要经过1s以后才能搜索的到。是什么原因导致的呢，我们就来更进一步的深入其中。

上面第2步当中的内存缓冲区中的内容是不能直接被搜索的，因为在lucene，只有一个打开的segment才能被搜索，此时缓冲区的内容还不是在一个段当中，但是缓冲区的内容会以固定的间隔刷新（默认为1秒）刷新的过程是:
1. 将内存缓冲区的内容写入文件系统缓存中的新段。此新段的内容更尚未被写入文件系统，但是分段是打开的，内容可被搜索。
2. 清空内存缓冲区。这里解释了搜索问什么是近实时的，也就是默认的情况下会有1s的延迟。
当然，这里的内存缓冲区刷新到文件系统缓存的节奏是可以控制的，我们可以通过设置"refresh_interval": "1s"来设置刷新的时间间隔;或者进行强制刷新POST /${index}/_refresh(但是这个在生产中不太建议频繁使用)
文件系统缓存中的数据会在满足一定的条件下进行持久化操作，写入磁盘，产生一个commit check point。

2.3 为什么要有translog

在前面讲es应对一次写入请求的过程中提到，在主片写入请求之前会先生成一个tranlog并进行持久化。那么为什么要有这个呢。

2.3.1 translog的作用

其实es的translog很好理解，基本上和其他系统中的各种用于记录的log类似，比如mysql中的binlog,redis中的aof日志，都是为了快速记录操作记录，防止因服务宕机等产生数据的丢失，当然binlog和aof log可能更加强大，因为他们保存的时间更久一些，可以直接用来做数据的回溯等操作。
在上面的介绍中我们也可以看到，es除了translog的记录使用的是同步持久化的方式,其他的操作都是对内存的操作，包括内存缓冲区和文件系统缓存都是对内存的操作。假如在这中间产生了一些意外，比如你不小心踢掉了插头(这个理由确实有点烂。。。)，那么内存缓冲区和 文件系统缓存中的内容都丢了，即使你插上了插头，重新启动了服务，也是无济于事啊。这个时候tranlog就要闪亮登场力挽狂澜了。因为tranlog在请求能够给客户端正确返回的时候一般都是保证了已经进行了持久化的(默认是都会持久化，你也可以配置成非同步持久化模式，下面会介绍),所以这个时候就可以将translog中的数据拿出来进行回放就行了（并不是全部回放，只是和已经持久化的最后一次commit check point 对比，将之后的tanslog进行重放就行了）。

2.3.2 translog的持久化机制

同时translog的持久化机制也是可以设置的，主要分为同步和异步两种，设置分别如下

index.translog.durability:request|async

request模式:这个是默认的模式，在每次写请求完成之后执行(index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。最终，基本上，这意味着在整个请求被 fsync 到主分片和复制分片的translog之前，你的客户端不会得到一个 200 OK 响应
async模式:会在后台异步的按照一个配置参数"index.translog.sync_interval": "5s"进行translog的异步持久化，但是突然宕机的话有可能会导致数据丢失。所以没有特殊情况，还是使用request 模式

2.3.2 commit产生的时机

es会在满足一定的条件下进行一次commit操作(也叫flush操作或者lucene commit),对应的条件是:

1.index.translog.flush_threshold_size : 这个是没有持久化的操作的最大数据存储量，默认是512mb
2.index.translog.retention.age: 这个设置了不再用于帮助lucene commit 持久化的translog能够保存的最长时间，默认是12h
3.index.translog.retention.size: 这个设置了不再用于帮助lucene commit 持久化的的translog的文件存储量,可以比flush_threshold_size更大

对于上面三个参数的翻译稍微有些模糊，从git的源码中找到的注释是这样说的
大概的意思是现在的flush操作只会提交lucene commit 并不会直接delete translog ，也就是把flush和delete translog分开为分别控制的了,也就是只有参数index.translog.flush_threshold_size会影响flush操作。这一段的解释主要是因为之前的老文档中有这样的解释中的第四点。

在进行flush操作时:

所有在内存缓冲区的文档都被写入一个新的段。
缓冲区被清空。
一个提交点被写入硬盘。
文件系统缓存通过 fsync 被刷新（flush）。
5. 老的 translog 被删除。这个目前应该不会立即删除了

refer
https://www.elastic.co/guide/cn/elasticsearch/guide/current/translog.html
https://blog.csdn.net/zg_hover/article/details/77171014

这个里面有说明flush并不是delete old translog
https://github.com/elastic/elasticsearch/blob/master/docs/reference/index-modules/translog.asciidoc