【Elasticsearch系列之二】ES数据存储可靠性和写入流程介绍

1、数据存储可靠性保证

1.1、引入translog

当一个文档写入Lucence后是存储在内存中的，即使执行了refresh操作仍然是在文件系统缓存中，如果此时服务器宕机，那么这部分数据将会丢失。为此ES增加了translog， 当进行文档写操作时会先将文档写入Lucene，然后写入一份到translog，写入translog是落盘的(如果对可靠性要求不是很高，也可以设置异步落盘，可以提高性能，由配置index.translog.durability和index.translog.sync_interval控制)，这样就可以防止服务器宕机后数据的丢失。由于translog是追加写入，因此性能比较好。与传统的分布式系统不同，这里是先写入Lucene再写入translog，原因是写入Lucene可能会失败，为了减少写入失败回滚的复杂度，因此先写入Lucene。

1.2、flush操作

每30分钟或当translog达到一定大小(由index.translog.flush_threshold_size控制，默认512mb)，ES会触发一次flush操作，此时ES会先执行refresh操作将buffer中的数据生成segment，然后调用lucene的commit方法将所有内存中的segment fsync到磁盘。此时lucene中的数据就完成了持久化，会清空translog中的数据(6.x版本为了实现sequenceIDs，不删除translog) 。

1.3、merge操作

由于refresh默认间隔为1s中，因此会产生大量的小segment，每个文件都需要有文件句柄，内存，CPU 使用等各种资源。为解决这个问题，ES会运行一个任务检测当前磁盘中的segment，对符合条件的segment进行合并操作，减少lucene中的segment个数，提高查询速度，降低负载。另外用户还可以手动调用_forcemerge API来主动触发merge，以减少集群的segment个数和清理已删除或更新的文档。

建议：forcemerge 线程对资源的消耗比普通的归并线程大得多，所以，绝对不建议对还在写入数据的热索引执行merge操作，如果要执行，也建议在业务低峰执行。

1.4、多副本机制

另外ES有多副本机制（默认是1个副本），一个分片的主副分片不能分片在同一个节点上，进一步保证数据的可靠性。

2、ES写索引的流程

ES写索引的流程

1) 用户创建了一个新文档，新文档被写入内存中；

2) 不时地缓存被提交，这时缓存中数据会以segment的形式被先写入到文件缓存系

统，而不是直接被刷到磁盘。这是因为，提交一个新的segment到磁盘需要一个fsync 来确保segment被物理性地写入磁盘，这样在断电的时候就不会丢失数据。 但是 fsync 操作代价很大，如果每次索引一个文档都去执行一次的话会造成很大的性能问题，但是这里新segment会被先写入到文件系统缓存，这一步代价会比较低；

3) 新的segment被写入到文件缓存系统，这时内存缓存被清空。在文件缓存系统会存

在一个未提交的segment。虽然新segment未被commit（刷到磁盘），但是文件已经在缓存中了，此时就可以像其它文件一样被打开和读取了；

4) 到目前为止索引的segment还未被刷新到磁盘，如果没有用 fsync 把数据从文件系

统缓存刷（flush）到硬盘，我们不能保证数据在断电甚至是程序正常退出之后依然存在。Elasticsearch 增加了一个 translog ，或者叫事务日志，在每一次对 Elasticsearch 进行操作时均进行了日志记录。如上图所示，一个文档被索引之后，就会被添加到内存缓冲区，并且同时追加到了 translog；

5) 每隔一段时间，更多的文档被添加到内存缓冲区和追加到事务日志（translog），之

后新segment被不断从内存缓存区被写入到文件缓存系统，这时内存缓存被清空，但是事务日志不会。随着 translog 变得越来越大，达到一定程度后索引被刷新，在刷新（flush）之后，segment被全量提交（被写入硬盘）。