第二篇：elasticsearch近实时搜索原理探究

本文基于elasticsearch版本7.10编写而成。

官方释义Elasticsearch, it is indexed and fully searchable in near real-time--within 1 second。那为啥是这样？我们探究下es数据写入的过程。

首先，数据会在 indexing buffer中，如图一。refresh操作后形成新的segment，如图二。新的segment首先是在文件系统缓存区，最后flush到磁盘中。

图一

图二

在Elasticsearch中，写入和打开新的segment的过程称为refresh。refresh使自上次refresh操作以来对索引执行的所有操作都可用于搜索。默认情况下，Elasticsearch每秒定期刷新索引，但仅限于在过去30秒内收到一个或多个搜索请求的索引。这就是为什么我们说Elasticsearch具有近乎实时的搜索：文档更改不能立即搜索，但在这个时间框架内会变得可见。

1、refresh。

1）文档操作请求地址后面加?refresh。

test索引新建一个id=1文档。

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

可选值：

空字符串或者 true:在操作发生后立即refresh相关的主分片和副本分片（不是整个索引），以便更新后的文档立即出现在搜索结果中。

wait_for:等待请求所做的更改通过refresh变得可见，然后再响应。

index.refresh_interval：执行refresh操作的频率，默认为1，可以设置为-1以禁用刷新。如果未显式设置此值，最近index.search.idle.after（默认30s）秒内，没有搜索流量的分片将不会收后到台刷新，直到它们收到搜索请求，搜索命中且正在等待刷新的空闲分片将进入下一次后台刷新（1秒内）。此机制旨在于，当不执行搜索时，自动优化，批量索引。为了退出此机制，应将该值显示设置为1s时间间隔。

false: 默认值。

2）refresh api

POST /my-index-000001/_refresh

2、flush。

POST /my-index-000001/_flush

flush操作是确保当前仅存储在事务日志中的任何数据也永久存储在Lucene索引中的过程。重新启动时，Elasticsearch将事务日志中的任何未刷新操作重放到Lucene索引中，使其恢复到重新启动前的状态。Elasticsearch根据需要自动触发flush，使用启发式方法，根据执行每次刷新的成本权衡未刷新事务日志的大小。

Elasticsearch flush是执行Lucene提交并开始新的translog生成的过程。flush在后台自动执行，以确保translog不会变得太大，这将使恢复期间重放其操作花费大量时间。

3、translog

对Lucene的更改仅在Lucene提交期间持久化到磁盘，这是一个相对昂贵的操作，因此不能在每次索引或删除操作后执行。如果进程退出或硬件故障，Lucene将从索引中删除在一次提交之后和另一次提交之前发生的更改。Lucene提交过于昂贵，无法对每个单独的更改执行，因此每个分片副本还将操作写入其事务日志（称为translog）。所有索引和删除操作都在内部Lucene索引处理后但在确认之前写入translog。在崩溃的情况下，当分片恢复时，已经确认但尚未包含在最后一次Lucene提交中的最近操作将从translog中恢复。

最后，今天先写的这儿吧，后面还会持续更新，欢迎点赞、评论、收藏，感谢大家的支持。