Telegram活跃群排行 亿级群组数据量下的分页性能优化：Scroll与Search After

当 Telegram 群组、频道、用户和消息索引达到亿级数据量后，传统的分页方式很容易从“看起来能用”变成“线上无法承受”。用户翻到较深页码时，查询延迟明显上升，内存占用持续增加，甚至会出现节点负载过高、结果重复或数据遗漏等问题。

在 Elasticsearch、OpenSearch 等搜索引擎中，Scroll 与 Search After 是两种常见的深度分页方案。它们解决的问题相似，但设计目标、资源模型、实时性和适用场景并不相同，必须结合数据规模与业务访问方式进行选择。

📌 一、为什么传统分页在亿级数据下会失效

最常见的分页请求通常使用 from 和 size 参数。例如查询第 10000 页，每页返回 20 条数据，搜索引擎并不是直接定位到第 200000 条记录，而是需要在每个分片上收集前 200020 条候选结果，再丢弃前面的数据。

{
  "from": 200000,
  "size": 20,
  "query": {
    "match": {
      "title": "技术群"
    }
  },
  "sort": [
    "_score",
    "_id"
  ]
}

随着页码加深，单次请求需要维护的候选结果越来越多，网络传输、排序和堆内存消耗都会增加。即使最终只返回 20 条数据，后台仍可能为这一页付出数百倍甚至数万倍的计算成本。

此外，亿级索引通常分布在多个分片中，每个分片都要参与排序和结果合并。分页深度越大，协调节点承受的压力越高，因此官方通常会限制 index.max_result_window，避免单个请求拖垮集群。

🔍 二、Scroll：适合稳定批量读取的快照分页

Scroll 的核心思想是为一次遍历任务创建相对稳定的搜索上下文。客户端首次发起查询后，搜索引擎会返回一个 scroll_id，后续请求通过这个标识继续读取下一批数据。

在滚动过程中，搜索引擎会尽量基于初始查询视图返回结果，因此适合全量导出、数据迁移、离线统计、重建索引和批量清洗等任务。对于需要连续读取数百万甚至数亿条记录的后台作业，Scroll 的行为通常更加可控。

Telegram活跃群排行 1. Scroll 的基本查询方式

POST /telegram_groups/_search?scroll=2m
{
  "size": 1000,
  "sort": ["_doc"],
  "query": {
    "term": {
      "status": "active"
    }
  }
}

首次请求的 size 应根据文档大小、网络带宽和节点负载进行压测，而不是盲目设置为很大。对群组索引而言，100 到 2000 条通常是一个需要实测的区间，最终数值应以平均延迟、堆内存和吞吐量为准。

POST /_search/scroll
{
  "scroll": "2m",
  "scroll_id": "DnF1ZXJ5VGhlbkZldGNo..."
}

2. Scroll 的资源风险

Scroll 并不是免费的游标。每个活跃的 scroll 上下文都会占用集群资源，如果客户端中途崩溃、网络断开或没有及时清理，大量上下文可能长期存在，进而影响搜索线程池和文件句柄。

因此，批处理程序必须设置合理的保留时间，并在任务完成后主动清理 scroll。建议同时限制并发任务数量，避免多个大规模导出任务叠加运行。

DELETE /_search/scroll
{
  "scroll_id": [
    "DnF1ZXJ5VGhlbkZldGNo..."
  ]
}

对于新版本 Elasticsearch，批量遍历场景还可以评估 PIT 配合 search_after。它在保持一致性视图的同时，通常比传统 Scroll 更适合现代搜索接口，但仍需要正确管理 PIT 的生命周期。

⚡ 三、Search After：适合用户连续浏览的深度分页

Telegram活跃群排行 Search After 不使用传统页码，而是使用上一页最后一条文档的排序值作为下一次查询的起点。搜索引擎会根据排序字段继续向后查找，从而避免维护庞大的前置结果集合。

这种方式特别适合群组搜索、频道目录、资源列表和后台审核页面。用户通常只会连续查看前几页，并不真正需要跳转到第 50000 页，此时“加载更多”或“下一页游标”比页码导航更高效。

1. 使用稳定排序字段

Search After 的关键是排序必须稳定、可比较，并且在多个分片之间具有足够的确定性。只使用相关性分数或时间字段可能造成排序值相同，建议增加一个唯一的 keyword 字段作为 tie-breaker。

POST /telegram_groups/_search
{
  "size": 20,
  "query": {
    "bool": {
      "filter": [
        { "term": { "status": "active" } }
      ],
      "must": [
        { "match": { "name": "开发者" } }
      ]
    }
  },
  "sort": [
    { "updated_at": "desc" },
    { "group_id": "asc" }
  ]
}

下一页需要把上一页最后一条记录的 sort 数组原样传回。排序字段的顺序必须完全一致，数据类型也必须保持一致，否则可能出现结果跳跃、重复或请求报错。

POST /telegram_groups/_search
{
  "size": 20,
  "query": {
    "match": {
      "name": "开发者"
    }
  },
  "sort": [
    { "updated_at": "desc" },
    { "group_id": "asc" }
  ],
  "search_after": [
    1718000123456,
    "tg_group_008821"
  ]
}

Telegram活跃群排行 2. Search After 的一致性问题

如果索引持续写入或更新，上一页与下一页之间的排序结果可能发生变化。比如某个群组在翻页期间被更新，排序位置发生移动，就可能导致用户看到重复记录，或者错过某些记录。

对实时搜索来说，这种变化通常是可以接受的，因为用户关注的是当前结果。对于导出、审计或需要严格一致性的任务，应使用 PIT 或其他固定时间点的读取方案。

🧭 四、Scroll 与 Search After 如何选择

如果目标是让用户在前端连续浏览群组结果，优先考虑 Search After。它不依赖深页码，单次请求的资源消耗更加平稳，也更适合高并发搜索接口。

如果目标是完整读取所有符合条件的文档，优先评估 Scroll 或 PIT 加 Search After。此类任务应运行在异步队列或独立的批处理服务中，不建议让浏览器直接持有长时间查询上下文。

推荐的业务决策表

用户搜索、列表浏览       -> Search After
后台全量导出、数据迁移     -> Scroll 或 PIT + Search After
严格一致性的数据快照       -> PIT + Search After
需要随机跳转页码           -> 重新设计交互，避免深度分页
高并发热门关键词查询       -> Search After + 缓存 + 限流

需要特别注意，Search After 并不支持传统意义上的“跳到第 N 页”。如果产品强制要求随机页码，应该重新评估用户真实需求，或者采用预计算游标、时间分段、按主键分区等方式降低跳页成本。

🛠️ 五、亿级群组索引的工程优化建议

1. 控制返回字段

搜索列表不需要返回群组简介、历史消息和全部统计字段。通过 _source includes 只返回列表所需字段，可以显著减少磁盘读取、序列化和网络传输成本。

{
  "_source": [
    "group_id",
    "name",
    "username",
    "member_count",
    "language",
    "updated_at"
  ],
  "size": 30
}

Telegram活跃群排行 2. 优先使用过滤条件

对于状态、语言、分类、是否公开等条件，应尽可能使用 filter。过滤条件不参与相关性评分，更容易利用缓存，并且比把所有条件放进全文检索更节省计算资源。

3. 设计合理的排序字段

排序字段需要具备明确业务含义，例如活跃度、更新时间、成员数量或综合质量分。排序字段应避免频繁变化，否则会降低翻页稳定性，也会增加索引更新压力。

4. 使用游标签名防止参数篡改

前端不应直接信任用户传入的 search_after 数组。服务端可以将查询条件、排序值、过期时间和用户标识封装后进行签名，防止用户修改游标读取不应访问的数据。

{
  "query_hash": "a91f...",
  "sort_values": [1718000123456, "tg_group_008821"],
  "expires_at": 1718003723,
  "signature": "hmac-sha256..."
}

5. 建立可观测性指标

性能优化不能只看接口平均响应时间，还应持续观察 P95 和 P99 延迟、查询取消率、协调节点 CPU、JVM 堆使用率、搜索线程池拒绝数以及各分片响应时间。

在实际压测中，应同时模拟热门关键词、低命中关键词、连续翻页、并发导出和索引实时写入。只有覆盖这些场景，才能判断方案是否能够承受真实流量。

❓ 常见问题解答（FAQ）

Search After 一定比 Scroll 快吗？

不一定。Search After 更适合在线连续分页，Scroll 更适合批量遍历。实际性能还取决于分片数量、查询条件、排序字段、文档大小、缓存命中率和并发规模。

为什么 Search After 会出现重复数据？

最常见原因是排序字段不稳定，或者索引在翻页期间发生了更新。为提高确定性，应使用唯一字段作为辅助排序，并在需要严格一致性时使用 PIT。

可以把 Scroll ID 长期保存在数据库吗？

不建议。Scroll ID 依赖搜索上下文和集群状态，存在生命周期限制。批处理程序应在有限时间内完成任务，并在结束后主动清理，不能把它当作永久游标。

每页返回多少条群组记录最合适？

Telegram活跃群排行 没有固定答案。可以从 20、50 或 100 条开始进行压测，并根据响应大小、移动端网络、接口延迟和节点资源逐步调整。前端体验与后端吞吐需要同时考虑。

亿级数据是否必须拆分索引？

不一定，但应根据写入速度、查询模式、生命周期和分片规模进行规划。可以按时间、地区或数据类型拆分，也可以使用索引生命周期管理，但应避免产生大量过小的索引和分片。

✅ 结语：让分页模型服务于真实场景

在亿级 Telegram 群组数据中，分页性能的核心并不是简单替换一个参数，而是重新设计查询路径、排序规则、数据返回量、游标生命周期和并发控制。传统 from/size 适合浅分页，深度分页则应根据业务选择 Search After、Scroll 或 PIT。

Telegram活跃群排行 面向用户的搜索列表，建议采用稳定排序的 Search After，并配合字段裁剪、过滤查询、游标签名和限流策略。面向后台的数据处理，则应使用受控的批量任务、合理的批次大小和完整的资源清理机制，最终通过压测与监控验证系统在真实流量下的稳定性。