Elasticsearch 被广泛认为是一种能够支持近实时（Near Real-Time, NRT）搜索的技术。这意味着当数据被索引后，几乎立刻（通常在几秒钟之内）就能被搜索到。不过，这里所说的“实时”实际上是指“接近实时”，因为从数据写入到能够被搜索之间还是存在一定的延迟。
实现NRT的关键机制
刷新（Refresh）：
- 默认情况下，Elasticsearch 每秒自动执行一次刷新操作。这意味着在大多数情况下，数据写入后最多等待1秒即可被搜索到。此外，也可以通过API手动触发刷新，让新数据立即可搜索。
索引段（Segment）：
- Elasticsearch 使用索引段来组织数据。每个索引段是一个独立的倒排索引。当数据被写入时，它们首先被写入内存缓冲区，随后定期或按需被刷新成一个新的索引段。这些索引段会被写入磁盘并打开供搜索使用。
事务日志（Translog）：
- 为了确保数据的可靠性，Elasticsearch 在数据写入内存缓冲区的同时，也会将数据写入事务日志。如果系统出现故障，可以通过重放事务日志中的操作来恢复数据。
提交点（Commit Point）：
- Lucene 使用提交点来跟踪哪些索引段是可以安全地用于搜索的。每当有新的索引段被刷新并写入磁盘后，就会创建一个新的提交点。搜索请求总是参考最新的提交点，以确保只访问已提交的数据。
Flush：
- Flush 是一个比 Refresh 更重的操作，它会将内存中的所有未刷写到磁盘的索引段强制写入磁盘，并清空事务日志。这不仅是为了确保数据在节点故障时不会丢失，也是为了防止事务日志过大导致恢复时间过长。
近实时搜索的权衡
虽然 Elasticsearch 的近实时特性为许多应用提供了快速响应和数据更新即时可见的能力，但在实现这些特性时也存在一些权衡：
- 延迟与资源消耗：更频繁的刷新可以减少数据变为可搜索的延迟，但这也会增加 CPU 和 I/O 资源的消耗，可能会影响系统的整体性能。
- 数据一致性：在刷新间隔内，新写入的数据可能还未对搜索可见。对于需要严格一致性的场景，可以通过设置合适的刷新策略或使用显式刷新 API 来减小这一窗口。
- 段数量控制：频繁的刷新会导致索引段的数量增加，这可能影响搜索性能。Elasticsearch 通过段合并机制来减少段的数量，同时释放存储空间。
总的来说，Elasticsearch 通过上述机制实现了高效且接近实时的搜索能力，适合需要快速响应和数据更新即时可见的应用场景。
