Elasticsearch (ES) 是一个高度可扩展的开源全文搜索引擎，它能够提供近实时 (Near Real-Time, NRT) 的搜索能力。这意味着，当你向 ES 中写入数据后，这些数据会在极短的时间内（通常是毫秒到秒级别）变得可搜索，但不是绝对意义上的实时。
近实时搜索的工作原理
数据写入与刷新 (Refresh)
- 当数据被写入 ES 时，它首先被存储在一个内存缓冲区 (In-Memory Buffer) 中。
- 定期（默认每秒一次），或者当缓冲区达到一定大小时，内存中的数据会被刷新 (Refresh) 到一个新的索引段 (Index Segment) 并打开供搜索使用。
- 用户也可以通过 API 手动触发刷新操作，以立即使新数据可搜索。
索引段 (Segment) 与倒排索引
- ES 基于 Apache Lucene 构建，Lucene 使用分段 (Segment) 存储数据。每个索引段都是一个独立的、已优化的倒排索引。
- 新数据先被加入内存中的索引段，刷新时，这个内存中的索引段被写入磁盘并加入到搜索范围中。
事务日志 (Translog) 与可靠性
- 为了确保数据的可靠性，ES 在数据写入内存缓冲区后，还会将其写入事务日志 (Transaction Log, Translog)。
- 如果系统崩溃或电源故障，重启后可以通过重放 Translog 中的操作恢复未刷新到磁盘的数据。
提交点 (Commit Point) 与数据可见性
- Lucene 使用提交点 (Commit Point) 跟踪哪些索引段是可以用于搜索的。当有新的索引段被刷新并认为安全时，就会创建一个新的提交点。
- 搜索请求总是参考最新的提交点，确保只访问已提交的、稳定的索引段。
Flush 与数据持久化
- 除了刷新操作，ES 还有一个 Flush 过程，它会将内存中的所有未刷写到磁盘的索引段强制写入磁盘，并清空 Translog。
- Flush 主要是为了解决 Translog 过大导致恢复时间过长的问题，以及确保数据在节点故障时不会丢失。
近实时搜索的权衡
- 延迟与资源消耗：更频繁的刷新可以减少数据变为可搜索的延迟，但会增加 CPU 和 I/O 资源的消耗。
- 数据一致性：在刷新间隔内，新写入的数据可能还未对搜索可见，这取决于刷新策略。
- 段数量控制：频繁的刷新会导致索引段数量增多，影响搜索性能。ES 通过段合并 (Merge) 机制来解决这个问题。
结论
Elasticsearch 的近实时搜索能力是通过一系列精心设计的数据处理流程实现的，它在保证高性能的同时，还能够提供几乎实时的数据更新可见性，这对于大多数应用程序来说已经足够满足需求。然而，对于需要绝对实时性的场景，可能需要进一步调整 ES 的配置或采取其他措施。
