@Elasticsearch之深度应用及原理剖析--索引文档写入和近实时搜索原理（基本概念，Es写操作流程，近实时搜索原理 ，持久化变更原理）

---

title: ElasticSearch之深度应用及原理剖析
author: YangShen
tags:

• 搜索引擎
• Elasticsearch
  categories:
• 搜索引擎
• Elasticsearch
  abbrlink: 5a1f6e0b

---

第1节 索引文档写入和近实时搜索原理

1.1 基本概念

Segments in Lucene
众所周知，Elasticsearch 存储的基本单元是 shard 分片， ES 中一个 Index 索引可能分为多个 shard， 事实上每个 shard 都是一个 Lucence 的 Index，并且每个 Lucence Index 由多个 Segment 段组成， 每个Segment 事实上是一些倒排索引的集合， 每次创建一个新的 Document ， 都会归属于一个新的Segment， 而不会去修改原来的 Segment 。且每次的文档删除操作，会仅仅标记 Segment 中该文档为删除状态， 而不会真正的立马物理删除， 所以说 ES 的 index 可以理解为一个抽象的概念。 就像下图所示：

Commits in Lucene
Commit 操作意味着将 Segment 合并，并写入磁盘。保证内存数据尽量不丢。但刷盘是很重的 IO 操作， 所以为了机器性能和近实时搜索， 并不会刷盘那么及时。

Translog
事务日志，新文档被索引意味着文档会被首先写入内存 buffer 和 translog 文件。每个 shard 都对应一个 translog文件

Refresh in Elasticsearch
在 Elasticsearch 中， _refresh 操作默认每秒执行一次， 意味着将内存 buffffer 的数据写入到一个新的 Segment 中，这个时候索引变成了可被检索的。写入新Segment后 会清空内存buffer。

Flush in Elasticsearch
Flush 刷新/盘操作 每30分钟或者translog 太大时，将内存 buffer 的数据全都写入新的 Segments 中， 并将内存中所有的 Segments全部刷盘， 并且清空 translog 日志的过程。

1.2 近实时搜索

从两个关键点：搜索和刷新下手
降低搜索代价：

提交（Commiting）一个新的段segment到磁盘需要一个 fsync 来确保segment段被物理性地写入磁盘，这样在断电的时候就不会丢失数据。 但是 fsync 落盘操作代价很大; 如果每次索引一个文档都去执行一次的话会造成很大的性能问题。
我们需要的是一个更轻量的方式来使一个文档可被搜索，这意味着 fsync 要从整个过程中被移除。
在 Elasticsearch 和磁盘之间是文件系统缓存。 像之前描述的一样，在内存索引缓冲区中的文档会被写入到一个新的段中。 但是这里新段会被先写入到文件系统缓存–这一步代价会比较低，稍后再被刷新到磁盘–这一步代价比较高。不过只要文件已经在系统缓存中， 就可以像其它文件一样被打开和读取了。
总结：使用文件系统缓存 File system cache 取消使用fsync落盘操作直接将新段刷新到磁盘才能够使文档可被搜索（代价很大），而是使用更轻量的方式：先将新段写入到文件系统缓存（代价比较低）便可以使文档可被搜索，稍后再刷新到磁盘

sync函数只是将所有修改过的块缓冲区排入写队列，然后就返回，它并不等待实际写磁盘操作结束。
通常称为update的系统守护进程会周期性地（一般每隔30秒）调用sync函数。这就保证了定期冲洗内核的块缓冲区。命令sync(1)也调用sync函数。
fsync函数只对由文件描述符filedes指定的单一文件起作用，并且等待写磁盘操作结束，然后返回。fsync可用于数据库这样的应用程序，这种应用程序需要确保将修改过的块立即写到磁盘上。
fdatasync函数类似于fsync，但它只影响文件的数据部分。而除数据外，fsync还会同步更新文件的属性。

在文件被 fsync 到磁盘前，被写入的文件在重启之后就会丢失。默认 translog 是每 5 秒被fsync 刷新到硬盘， 或者在每次写请求完成之后执行(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。这意味着在整个请求被 fsync 到主分片和复制分片的 translog 之前，你的客户端不会得到一个 200 OK 响应。
在每次写请求后都执行一个 fsync 会带来一些性能损失，尽管实践表明这种损失相对较小（特别是 bulk 导入，它在一次请求中平摊了大量文档的开销）。
但是对于一些大容量的偶尔丢失几秒数据问题也并不严重的集群，使用异步的 fsync 还是比较有益的。比如，写入的数据被缓存到内存中，再每 5 秒执行一次 fsync 。
这个行为可以通过设置 durability 参数为 async 来启用：

PUT /my_index/_settings 
{
  "index.translog.durability": "async",
  "index.translog.sync_interval": "5s" 
}

这个选项可以针对索引单独设置，并且可以动态进行修改。如果你决定使用异步 translog 的话，你需要保证在发生 crash 时，丢失掉 sync_interval 时间段的数据也无所谓。请在决定前知晓这个特性。
如果你不确定这个行为的后果，最好是使用默认的参数（ “index.translog.durability”: “request” ）来避免数据丢失。

														**图 19. 在内存缓冲区中包含了新文档的 Lucene 索引**

Lucene 允许新段被写入和打开–使其包含的文档在未进行一次完整提交时便对搜索可见。 这种方式比进行一次提交代价要小得多，并且在不影响性能的前提下可以被频繁地执行。

总结：不提交 Commiting 缓冲区的内容已经被写入一个可被搜索的新段中，但还没有进行提交 这种方式比进行一次提交Commiting代价要小得多，并且在不影响性能的前提下可以被频繁地执行
图 20. 缓冲区的内容已经被写入一个可被搜索的新段中，但还没有进行提交

提高刷新速度：

原理
下图表示是 es 写操作流程，当一个写请求发送到 es 后，es 将数据写入 memory buffer 中，并添加事务日志（ translog ）。如果每次一条数据写入内存后立即写到硬盘文件上，由于写入的数据肯定是离散的，因此写入硬盘的操作也就是随机写入了。硬盘随机写入的效率相当低，会严重降低es的性能。
因此 es 在设计时在 memory buffer 和硬盘间加入了 Linux 的高速缓存（ File system cache ）来提高 es 的写效率。当写请求发送到 es 后，es 将数据暂时写入 memory buffer 中，此时写入的数据还不能被查询到。默认设置下，es 每1秒钟将 memory buffer 中的数据 refresh （将内存 buffer 的数据写入到一个新的 Segment 中）到 Linux 的 File system cache 文件系统缓存，并清空 memory buffer 内存 ，此时写入的数据就可以被查询到了。

总结：使用高速缓存（文件系统缓存） File system cache es 在设计时在 memory buffer 和硬盘间加入了 Linux 的高速缓存 File system cache 。将新段写入到高速缓存来提高 es 的写效率

refresh API
在 Elasticsearch 中，写入和打开一个新段的轻量的过程叫做 _refresh _。 默认情况下每个分片会每秒自动刷新一次。这就是为什么我们说 Elasticsearch 是近实时搜索： 文档的变化并不是立即对搜索可见，但会在一秒之内变为可见。
这些行为可能会对新用户造成困惑： 他们索引了一个文档然后尝试搜索它，但却没有搜到。这个问题的解决办法是用 refresh API 执行一次手动刷新：

POST /_refresh 
POST /my_blogs/_refresh 
PUT /my_blogs/_doc/1?refresh 
{
   "test": "test"
} 

PUT /test/_doc/2?refresh=true
{
   "test": "test"
}

1. 刷新（Refresh）所有的索引。
2. 只刷新（Refresh） blogs 索引
3. 只刷新文档

并不是所有的情况都需要每秒刷新。可能你正在使用 Elasticsearch 索引大量的日志文件， 你可能想优化索引速度而不是近实时搜索， 可以通过设置 refresh_interval ， 降低每个索引的刷新频率。

PUT /my_logs
{ 
  "settings": { 
    "refresh_interval": "30s"
  }
}

refresh_interval 可以在既存索引上进行动态更新。 在生产环境中，当你正在建立一个大的新索引时，可以先关闭自动刷新，待开始使用该索引时，再把它们调回来：

PUT /my_logs/_settings 
{
  "refresh_interval": -1 
}

PUT /my_logs/_settings 
{
  "refresh_interval": "1s"
}

1.3 持久化变更

原理
如果没有用 fsync 把数据从文件系统缓存刷（flush）到硬盘，我们不能保证数据在断电甚至是程序正常退出之后依然存在。所以即使通过每秒刷新（refresh）实现了近实时搜索，我们仍然需要经常进行完整提交来确保能从失败中恢复。
为了保证 Elasticsearch 的可靠性，需要确保数据变化被持久化到磁盘。
在动态更新索引时，我们说一次完整的提交Commiting会将段刷到磁盘，并写入一个包含所有段列表的提交点。Elasticsearch 在启动或重新打开一个索引的过程中使用这个提交点来判断哪些段隶属于当前分片。
即使通过每秒刷新（refresh）实现了近实时搜索，我们仍然需要经常进行完整提交来确保能从失败中恢复。**但在两次提交之间发生变化的文档怎么办？**我们也不希望丢失掉这些数据。
Elasticsearch 增加了一个 _translog _，或者叫事务日志，在每一次对 Elasticsearch 进行操作时均进行日志记录。通过 translog ，整个流程看起来是下面这样：

1. 一个文档被索引之后，就会被添加到内存缓冲区，并且 追加到了 translog ，正如 图21描述的一样。

图 21. 新的文档被添加到内存缓冲区并且被追加到了事务日志

1. 刷新（refresh）使分片处于 图 22描述的状态，分片每秒被刷新（refresh）一次：

• 这些在内存缓冲区的文档被写入到一个新的段中，且没有进行 fsync 操作。
• 这个段被打开，使其可被搜索。
• 内存缓冲区被清空。

图 22. 刷新（refresh）完成后， 缓存被清空但是事务日志不会

3.这个进程继续工作，更多的文档被添加到内存缓冲区和追加到事务日志（见 图 23 ）。

图23事务日志不断积累文档

3.每隔一段时间–例如 translog 变得越来越大–索引被刷新（flush）；一个新的 translog 被创建，
并且一个全量提交被执行（见图 24）：

• 所有在内存缓冲区的文档都被写入一个新的段。
• 缓冲区被清空。
• 一个提交点被写入硬盘。
• 文件系统缓存通过 fsync 被刷新（flush）。
• 老的 translog 被删除。

translog 提供所有还没有被刷到磁盘的操作的一个持久化纪录。当 Elasticsearch 启动的时候， 它会从磁盘中使用最后一个提交点去恢复已知的段，并且会重放 translog 中所有在最后一次提交后发生的变更操作。
translog 也被用来提供实时 CRUD 。当你试着通过 ID 查询、更新、删除一个文档，它会在尝试从相应的段中检索之前， 首先检查 translog 任何最近的变更。这意味着它总是能够实时地获取到文档的最新版本。

图 24. 在刷新（flush）之后，段被全量提交，并且事务日志被清空。

flush API
这个执行一个提交并且截断 translog 的行为在 Elasticsearch 被称作一次 _flush _。 分片每 30 分钟被自动刷新（flush），或者在 translog 太大的时候也会刷新。
flush API 可以 被用来执行一个手工的刷新（flush）:

POST /blogs/_flush 
POST /_flush?wait_for_ongoin

1. 刷新（flush） blogs 索引。
2. 刷新（flush）所有的索引并且等待所有刷新在返回前完成。
   我们很少需要自己手动执行一个的 flush 操作；通常情况下，自动刷新就足够了。
   这就是说，在重启节点或关闭索引之前执行 flush有益于你的索引。当 Elasticsearch 尝试恢复或重新打开一个索引，它需要重放 translog 中所有的操作，所以如果日志越短，恢复越快。
   Translog 有多安全？
   translog 的目的是保证操作不会丢失。这引出了这个问题： Translog 有多安全？
   在文件被 fsync 到磁盘前，被写入的文件在重启之后就会丢失。默认 translog 是每 5 秒被fsync 刷新到硬盘， 或者在每次写请求完成之后执行(e.g. index, delete, update, bulk)。这个过程在主分片和复制分片都会发生。这意味着在整个请求被 fsync 到主分片和复制分片的 translog 之前，你的客户端不会得到一个 200 OK 响应。
   在每次写请求后都执行一个 fsync 会带来一些性能损失，尽管实践表明这种损失相对较小（特别是 bulk 导入，它在一次请求中平摊了大量文档的开销）。
   但是对于一些大容量的偶尔丢失几秒数据问题也并不严重的集群，使用异步的 fsync 还是比较有益的。比如，写入的数据被缓存到内存中，再每 5 秒执行一次 fsync 。
   这个行为可以通过设置 durability 参数为 async 来启用：

PUT /my_index/_settings 
{
  "index.translog.durability": "async",
  "index.translog.sync_interval": "5s" 
}

这个选项可以针对索引单独设置，并且可以动态进行修改。如果你决定使用异步 translog 的话，你需要保证在发生 crash 时，丢失掉 sync_interval 时间段的数据也无所谓。请在决定前知晓这个特性。
如果你不确定这个行为的后果，最好是使用默认的参数（ “index.translog.durability”: “request” ）来避免数据丢失。