入门：ElasticSearch(es)持久化机制

ElasticSearch持久化机制(near real time)

1、名词概念

doc：每一条记录，亦称文档

segment：分段记录，包含正排（空间占比90~95%）+ 倒排（空间占比5~10%）的完整索引文件

refresh：内存缓存区加载到文件缓存区的过程

flush：文件缓存区落地到磁盘的过程

commit point：提交标志

2、持久化

持久化流程：

1. 数据分别插入translog事务日志和内存缓存区中；

2. 内存缓存区满了或者每隔1秒(默认1秒)，refresh将内存缓存区的数据生成index segment文件并写入文件系统缓存区，此时index segment可被打开以供

   search查询读取，这样文档就可以被搜索到了（注意，此时文档还没有写到磁盘上），但内存缓存区中的doc记录无法被search。refresh之后内存缓存区的

   doc将被清空；

3. 重复上两个步骤，新的segment不断添加到文件系统缓存区，内存缓存区不断被清空，而translog的数据不断增加，随着时间的推移，translog文件会越来越大。

4. 当translog长度达到一定程度的时候，会触发flush *** 作，否则默认每隔30分钟也会定时flush，其主要过程：

   ​ 4.1.执行refresh *** 作，将内存缓存区中的数据写入到新的segment并写入文件系统缓存区，然后打开本segment以供search使用，最后再次清空内存缓存区；
   ​ 4.2.一个commit point被写入磁盘，这个commit point中标明所有的index segment；

   ​ 4.3.文件系统中缓存的所有的index segment文件被异步(fsync)强制刷到磁盘，当index segment被fsync强制刷到磁盘上以后，就会被打开，供查询使用；

   ​ 4.4.translog被清空和删除，创建一个新的translog；
   
   

3、translog作用

​有人可能会好奇，translog如果跟真实数据没差，为什么还要一边将doc记录到translog一边记录到内存缓存区？其实话里就已经给出了答案。

​translog跟Mysql中的binlog，Redis中的aof日志一样都是为了快速记录 *** 作记录，防止因服务宕机等产生数据的丢失（当然它们相对强大一些，可以保存更久，以便用来做rollback）。此外，事务日志采用的是追加的方式，因此写日志的 *** 作是磁盘上一小块区域内的顺序I/O，而不像随机I/O需要在磁盘的多个地方移动磁头，所有采用事务日志的方式相对来说要快得多，内存中被修改的数据在后台可以慢慢地刷回到磁盘。

doc记录在缓存中是es性能的体现，而为了防止断电过程中缓存数据丢失，因此es又需要引入translog记录doc，即便缓存中的数据丢失，断电恢复后，es又可以从translog中恢复数据，至于从什么时候开始恢复，取决于已经持久化的最后一次最后一次commit check point。

​不管是put是新增还是修改或者删除，每条doc都需要 *** 作两次磁盘，一遍是事务，一遍是flush。

4、segment merge流程

​Segment事实上是一些倒排索引的集合，只有经历了refresh *** 作之后，数据才能变成可检索。ElasticSearch每次refresh一次都会生成一个新的Segment文件，这样下来Segment文件就会越来越多。那这样会导致什么问题呢？因为每个Segment都会占用文件句柄、内存、cpu资源，更重要的是，每个搜索请求都必须访问每一个Segment，这就意味着存在的Segment越多，搜索请求就会变得越慢。

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

5、THANKS FOR

文章摘抄知乎影语无声和CSDN夜月行者