4. 实时搜索架构：实时索引更新机制、内存索引与磁盘索引的协同、典型实时搜索系统（如Elasticsearch）

实时搜索架构的核心目标是：文档一旦被写入，立即可被搜索到。与近实时搜索不同，实时搜索不依赖固定的刷新间隔（如 Elasticsearch 的 1 秒刷新），而是通过主动刷新或同步写入机制，将索引延迟压缩到毫秒级。本章深入剖析实时索引的更新机制、内存与磁盘的协同策略，并以 Elasticsearch 的实时搜索能力为例进行说明。

4.1 实时索引更新机制

实时索引更新通常采用以下三种机制之一，或组合使用：

4.2 内存索引与磁盘索引的协同

实时搜索架构必须解决一个核心矛盾：内存索引速度快但容量有限且易失，磁盘索引容量大但访问延迟高。现代实时搜索系统采用分层协同策略，将索引分为三个层级：

1. 内存缓冲区（Memory Buffer）：接收新写入的文档，暂存为未提交的倒排列表。此区域仅用于写入，不可搜索。
2. 可搜索内存段（Searchable In-Memory Segment）：当缓冲区达到一定大小或收到主动刷新指令时，缓冲区被转换为一个完整的倒排索引段，并放入内存中的段列表。该段立即可被搜索。
3. 磁盘段（Disk Segment）：后台线程定期将内存段合并（Merge）并刷写到磁盘，形成不可变的磁盘段。磁盘段同样参与搜索，但查询时需要从磁盘加载。

下图展示了实时搜索中内存索引与磁盘索引的协同工作流程：

4.3 典型实时搜索系统：Elasticsearch 的实时能力

Elasticsearch 本质上是一个近实时搜索引擎（默认 1 秒刷新间隔），但通过以下配置和 API 调用，可以将其行为调整为实时搜索：

4.3.1 实时 GET 操作

Elasticsearch 提供了 GET /index/_doc/{id} 操作，该操作不依赖索引刷新，而是直接从 Translog（事务日志） 中读取最新文档内容。即使文档尚未被刷新到段中，也能立即返回。

# 实时获取文档，无需等待刷新
GET /my_index/_doc/123
# 返回结果包含最新写入的字段

4.3.2 强制刷新实现实时搜索

在写入后立即调用 _refresh API，可以强制将缓冲区中的文档变为可搜索状态：

# 写入文档
POST /my_index/_doc
{
  "title": "实时搜索测试",
  "content": "这条文档写入后立即可搜"
}

# 强制刷新，使文档可见
POST /my_index/_refresh

# 立即搜索
GET /my_index/_search
{
  "query": {
    "match": { "title": "实时搜索" }
  }
}

4.3.3 实时搜索与近实时搜索的配置对比

4.4 实时搜索架构的挑战与优化

• 写放大（Write Amplification）：每次强制刷新都会生成一个新段，后续合并时需重写大量数据。优化策略包括：增大刷新阈值（如每 1000 条文档或 100ms 才刷新一次），或使用 异步刷新 模式。
• 内存压力：可搜索内存段驻留在堆内存或文件系统缓存中，过多内存段会挤占查询缓存。优化策略：设置 index.translog.sync_interval 和 index.merge.scheduler.max_thread_count 以加速合并。
• 查询合并开销：实时搜索需要同时扫描内存段和磁盘段，查询结果合并（Result Merge）的复杂度随段数线性增长。优化策略：使用 段预过滤（Segment Pre-filtering） 技术，跳过不包含匹配文档的段。