Elasticsearch原理：十张图给你说的清楚！

• 不断将 Document 写入到 In-memory buffer（内存缓冲区）。
• 当满足一定条件后内存缓冲区中的 Documents 刷新到高速缓存（cache）。
• 生成新的 segment，这个 segment 还在 cache 中。
• 这时候还没有 commit，但是已经可以被读取了。

画图如下：

PUT /test/_doc/1?refresh
{“test”: “test”}// 或者
PUT /test/_doc/2?refresh=true
{“test”: “test”}

Translog 事务日志

此处可以联想 MySQL 的 binlog，ES 中也存在一个 translog 用来失败恢复：

• Document 不断写入到 In-memory buffer，此时也会追加 translog。
• 当 buffer 中的数据每秒 refresh 到 cache 中时，translog 并没有进入到刷新到磁盘，是持续追加的。
• translog 每隔 5s 会 fsync 到磁盘。
• translog 会继续累加变得越来越大，当 translog 大到一定程度或者每隔一段时间，会执行 flush。

• buffer 被清空。
• 记录 commit point。
• cache 内的 segment 被 fsync 刷新到磁盘。
• translog 被删除。

• translog 每 5s 刷新一次磁盘，所以故障重启，可能会丢失 5s 的数据。
• translog 执行 flush 操作，默认 30 分钟一次，或者 translog 太大也会执行。

POST /my-index-000001/_flush

所以每次 commit， 生成 commit point 时，会有一个 .del 文件，里面会列出被删除的 document（逻辑删除）。

而查询时，获取到的结果在返回前会经过 .del 过滤。更新时，也会标记旧的 docment 被删除，写入到 .del 文件，同时会写入一个新的文件。

• refresh 操作会创建新的 segment 并打开以供搜索使用。
• 合并进程选择一小部分大小相似的 segment，并且在后台将它们合并到更大的 segment 中。这并不会中断索引和搜索。
• 当合并结束，老的 segment 被删。

说明合并完成时的活动：

• 新的 segment 被刷新（flush）到了磁盘。 写入一个包含新 segment 且排除旧的和较小的 segment的新 commit point。
• 新的 segment 被打开用来搜索。
• 老的 segment 被删除。

• 准实时搜索：https://www.elastic.co/guide/en/elasticsearch/reference/7.9/near-real-time.html
• Refresh API：https://www.elastic.co/guide/en/elasticsearch/reference/7.9/indices-refresh.html
• Flush API：https://www.elastic.co/guide/en/elasticsearch/reference/7.9/indices-flush.html