关系梳理

ES底层使用的是Lucene库，ES的分片（shard ）是Lucene的索引，ES的索引是分片的集合，Lucene的索引是由多个段（segment）组成。

在这里插入图片描述

段（segment）

Per-segment search，也即按段搜索，是Lucene中的概念。每个段本身就是一个倒排索引，Lucene中的索引除了表示段的集合外，还增加了提交点的概念，一个提交点就是一个列出了所有已知段的文件。

在这里插入图片描述

Per-segment search的工作流程如下：

新的文档首先被写入内存区的索引缓存（buffer）。
不时，这些buffer被提交。
新段被打开，它包含的文档可以被检索。
内存的缓存被清除，等待接收新的文档。

在这里插入图片描述

提交

一次完整的提交会将段刷到磁盘，并写入一个包含所有段列表的提交点。ES在启动或重新打开一个索引的过程中使用这个提交点来判断哪些段隶属于当前分片。

不可变性

写入磁盘的倒排索引是不可变的，也即段是不可改变的，所以既不能把文档从旧的段中移除，也不能修改旧的段来更新文档。取而代之的是，每个提交点会包含一个 .del 文件，它记录了段中被删除的文档。

当一个文档被 “删除” 时，它实际上只是在 .del 文件中被标记为删除。一个被标记为删除的文档仍然可以被查询匹配到，但它会在最终结果被返回前从结果集中移除。

文档更新也是类似的操作方式：当一个文档被更新时，旧版本文档被标记为删除，文档的新版本被索引到一个新的段中。可能两个版本的文档都会被一个查询匹配到，但被删除的那个旧版本文档在结果集返回前会被移除。

近实时搜索

提交一个新的段到磁盘需要调操作系统的fsync方法，确保段被物理地写入磁盘，即使断电也不会丢失数据。但是fsync是昂贵的，它不能在每个文档被索引时就触发。所以需要一种更轻量级的方式使新的文档可以被搜索。

位于ES和磁盘间的是文件系统缓存。在内存索引缓存中的文档被写入新的段，新的段首先写入文件系统缓存，这代价很低，之后会被同步到磁盘，这代价很大。一旦一个文件被缓存，它也可以被打开和读取，就像其他文件一样。

在这里插入图片描述

Refresh

在ES中，refresh是指这样一个过程：将In-memory buffer中的文档写入到文件系统缓存中新的段，新的段被打开（可被搜索）。默认情况下每个分片会每秒自动刷新一次。文档在In-memory buffer中是不能被搜索的，写入到段里面才能被搜索。这就是为什么我们说Elasticsearch是近实时搜索: 文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。

Flush

在ES中，进行一次提交并删除事务日志的操作叫做flush。一些老资料说ES每30分钟flush一次，或者事务日志过大也会flush。官网最新的说法是ES根据需要自动触发刷新，主要取决于事务日志的大小和权衡执行flush的成本。也可以调用flush API主动flush。

Translog

Translog全称transaction log（事务日志）。事务日志主要是为了防止在两次提交之间的数据丢失。事务日志也被用来提供实时 CRUD ，当你通过文档ID查询、更新、删除一个文档，在从相应的段检索之前， ES会首先检查事务日志最新的改动，这意味着ES总是能够通过文档ID实时地获取到文档的最新版本。

事务日志并不是实时落盘的，而是定期刷到磁盘。所以事务日志其实也是存在丢失的可能性的。那么这里就有一个问题，既然调用fsync的提交是一种昂贵的操作，为了防止数据丢失引入了事务日志，但是事务日志也需要刷到磁盘才能保证数据不丢，那事务日志的意义何在？答案是事务日志的刷盘更轻量级，因为它调用的是fdatasync这个系统函数，而不是fsync。感兴趣的可以了解下fsync和fdatasync的差别。