Telegram万能搜索Bot 亿级机器人数据量下的分页性能优化：Scroll与Search After

Telegram万能搜索Bot 当机器人、日志采集器、搜索爬虫或业务事件系统持续写入数据时，Elasticsearch 很容易进入亿级文档规模。此时，传统的 from + size 分页方式会逐渐暴露性能瓶颈：页码越深，查询需要跳过的数据越多，协调节点的排序、堆内存和网络压力也会同步上升。

面对深度分页，工程实践中最常见的两种方案是 Scroll 与 Search After。二者都能绕开传统分页的部分限制，但适用场景、资源模型、数据一致性和运维风险并不相同。

🤖 一、为什么亿级数据不能依赖传统分页

传统分页通常使用 from: 0, size: 20 查询第一页，使用 from: 1000000, size: 20 查询深页。虽然客户端只需要 20 条结果，但 Elasticsearch 往往必须先收集并排序前面的 1,000,020 条候选文档，再丢弃前 1,000,000 条。

这意味着深页查询的成本会随着页码增长而增加，并可能触发 Result window is too large 错误。直接调高 index.max_result_window 并不是根本解决方案，因为它只是放宽限制，同时会放大内存消耗和集群抖动风险。

对于机器人批量读取、历史数据导出、离线清洗等任务，系统关注的不是“用户翻到了第几页”，而是“能否稳定地遍历全部匹配文档”。对于在线搜索结果，系统更关注低延迟、连续翻页和对新数据变化的合理处理。

🧭 二、Scroll：适合批处理，不适合普通用户翻页

Scroll 会在服务端创建一个滚动上下文，后续请求通过 scroll_id 继续读取上一批结果。它更像一个面向批处理的游标，能够减少每一页重新计算查询结果的成本。

在早期 Elasticsearch 版本中，Scroll 经常被用于深度分页。对于大规模数据迁移、全量导出、离线索引重建和机器人批量处理，它仍然具有实用价值，但使用者必须主动管理上下文的生命周期。

📦 基础 Scroll 请求示例

POST /robots-*/_search?scroll=2m
{
  "size": 1000,
  "sort": ["_doc"],
  "query": {
    "range": {
      "created_at": {
        "gte": "now-30d"
      }
    }
  }
}

第一次请求会返回结果和 _scroll_id。之后客户端应使用该标识继续请求，而不是重复执行原始查询。每次只取适合系统吞吐能力的批量大小，例如 500、1000 或 2000 条，不能盲目追求单批越大越好。

POST /_search/scroll
{
  "scroll": "2m",
  "scroll_id": "原始响应中的_scroll_id"
}

⚠️ Scroll 的资源与风险

Scroll 上下文会占用集群资源，并且可能保持较长时间的搜索视图。机器人任务如果中途崩溃、网络断开或没有及时清理，就可能留下大量无效上下文，增加文件句柄、堆内存和查询线程压力。

因此，任务结束后必须主动清理 Scroll。对于超大规模任务，还可以使用 Sliced Scroll 将任务拆成多个切片，并结合并发度限制，避免单个任务长时间独占集群资源。

DELETE /_search/scroll
{
  "scroll_id": [
    "已经完成任务的_scroll_id"
  ]
}

🚀 三、Search After：在线连续分页的优先选择

Search After 不保存传统意义上的页码，而是使用上一页最后一条文档的排序值作为下一页的起点。查询不需要跳过前面所有结果，因此在深度遍历场景下通常比 from + size 更稳定。

它特别适合无限滚动列表、消息流、机器人搜索结果、时间线和需要持续加载下一批数据的接口。客户端必须保存上一页最后一条记录的 sort 值，并将其传递给下一次请求。

POST /robots-*/_search
{
  "size": 50,
  "query": {
    "bool": {
      "filter": [
        {
          "term": {
            "status": "active"
          }
        }
      ]
    }
  },
  "sort": [
    {
      "created_at": "desc"
    },
    {
      "_shard_doc": "asc"
    }
  ],
  "search_after": [
    "2025-01-01T12:30:00.000Z",
    987654
  ],
  "_source": [
    "robot_id",
    "name",
    "created_at",
    "status"
  ]
}

排序字段必须具备稳定性和可比较性。仅使用可能重复的时间字段并不理想，因为多条文档可能拥有完全相同的时间戳，建议增加一个唯一或近似唯一的稳定排序键作为 tie-breaker。

需要注意，Search After 本身不等于完全一致的快照。索引在翻页过程中持续写入、更新或删除时，结果可能出现重复或遗漏，因此对强一致遍历要求较高的任务，应结合 Point In Time 使用。

🔒 四、PIT + Search After：兼顾稳定性与性能

Telegram万能搜索Bot Point In Time，简称 PIT，可以在一段时间内固定搜索视图。客户端先创建 PIT，再使用 PIT ID 和 Search After 连续读取，这样每一页使用的是相对一致的索引快照。

POST /robots-*/_pit?keep_alive=2m

Telegram万能搜索Bot 创建成功后，查询请求中应携带 PIT，并在排序中使用 _shard_doc 作为稳定的内部排序字段。每次翻页都应刷新合理的 keep_alive，任务完成后主动关闭 PIT，避免快照资源长期占用。

POST /_search
{
  "pit": {
    "id": "当前PIT_ID",
    "keep_alive": "2m"
  },
  "size": 1000,
  "sort": [
    {
      "created_at": "asc"
    },
    {
      "_shard_doc": "asc"
    }
  ],
  "search_after": [
    "2024-01-01T00:00:00.000Z",
    123456
  ],
  "query": {
    "match_all": {}
  }
}

在亿级机器人数据场景中，PIT 的存活时间不宜设置得过长。更合理的做法是控制单次任务时长、设置超时和重试策略，并监控 PIT 数量、搜索线程池、JVM 堆使用率以及节点磁盘压力。

⚙️ 五、亿级数据分页的实战优化清单

1. 只返回真正需要的字段

使用 _source 过滤减少响应体积，避免把完整日志、超长描述和无关嵌套字段全部返回。网络传输量下降后，序列化、反序列化和客户端内存占用也会同步降低。

2. 优先使用 Filter

对于状态、租户、时间范围和机器人类型等精确条件，应优先放入 bool.filter。Filter 不参与相关性评分，更容易利用缓存，并且表达了查询只需要筛选而非全文排序的意图。

3. 控制批量大小与并发度

Telegram万能搜索Bot 批量大小过小会增加请求次数，过大则会造成单次响应延迟、GC 抖动和下游消费堆积。建议通过压测确定合理值，并根据集群负载动态调整并发，而不是固定开启大量机器人任务。

4. 建立可恢复的游标机制

不要只在内存中保存最后一次分页位置。生产系统可以持久化任务 ID、PIT 状态、最后一条排序值和已处理数量，配合幂等写入，使任务在网络故障或进程重启后能够继续执行。

5. 避免深分页中的高成本排序

排序字段应使用合适的映射类型，并尽量避免对分析文本字段直接排序。对于高频时间线查询，可以通过合理的索引按月或按天拆分、冷热分层和时间过滤来减少需要扫描的分片数量。

📊 六、Scroll 与 Search After 如何选择

如果目标是一次性读取大量数据，并将结果交给离线程序、数据仓库或迁移工具处理，优先考虑 Scroll 或带切片的 Scroll。它的批处理语义更直接，但必须设置超时、限制并发并清理上下文。

如果目标是面向用户的连续加载、机器人接口分页或在线检索，优先使用 Search After。如果翻页期间的数据变化会影响准确性，则采用 PIT + Search After，并设计 PIT 失效后的任务重建逻辑。

简单来说，Scroll 更像“批量导出游标”，Search After 更像“在线结果游标”。选择方案时，不应只比较单次查询耗时，还要综合考虑数据一致性、资源占用、失败恢复、并发控制和业务可接受的重复率。

❓ 常见问题解答（FAQ）

Search After 能否直接跳到第 10000 页？

不能。Search After 是顺序游标机制，必须携带上一页的排序值，不支持像传统分页一样根据页码随机跳转。如果业务必须跳页，应重新设计交互，或使用可定位的业务字段作为查询条件。

Scroll 是否一定比 Search After 快？

Telegram万能搜索Bot 不一定。Scroll 更适合固定快照下的批量遍历，Search After 更适合在线连续读取。真正性能取决于查询条件、排序方式、分片数量、批量大小、并发度以及返回字段数量。

为什么分页结果会出现重复或遗漏？

常见原因包括排序字段不唯一、分页期间发生文档更新，以及不同请求看到的索引刷新状态不同。使用稳定排序键和 PIT 可以降低风险，同时应让下游处理具备幂等性。

机器人批量任务应该如何监控？

建议监控每批耗时、吞吐量、失败重试次数、最后游标、PIT 或 Scroll 数量、JVM 内存、搜索线程池拒绝数和下游消费延迟。只有将这些指标纳入告警，才能在亿级数据增长后及时发现分页系统退化。

在亿级机器人数据量下，分页优化的核心不是简单替换一个 API，而是建立适合业务目标的读取模型。批处理选择 Scroll，在线连续分页选择 Search After，需要一致性时使用 PIT + Search After，再配合字段裁剪、合理排序、并发限制和可恢复机制，才能让系统在数据持续增长时依然保持稳定。