从深分页卡顿到毫秒响应：一次真实的 ES 客户端分页优化实践
你有没有遇到过这样的场景？前端同学点开日志查询页面，翻到第 500 页时，接口直接卡了七八秒才返回——用户以为系统崩了，运维却在后台看着协调节点的 CPU 疯狂飙升。这背后，往往藏着一个被忽视的技术细节：Elasticsearch 的分页方式选错了。
在我们负责的日志平台中，这个问题一度成为性能瓶颈的核心。每天千万级新增日志，from + size分页在第 1000 页后响应时间突破 8 秒，GC 频发，集群负载不均。最终，我们通过重构es客户端的分页逻辑，将平均延迟压降 87%，协调节点压力下降超六成。
今天，我就带你一步步还原这场实战优化全过程，讲清楚from+size到底为什么慢，Scroll 和 Search After 又该如何正确使用。
一、问题起点：谁动了我的性能？
我们的系统架构很典型：
[前端] → [API 网关] → [Java 后端服务（es客户端）] → [ES 集群]最初为了快速上线，采用最简单的from + size实现分页。前端传个page=100&size=10，后端换算成from=990, size=10直接转发给 ES。
起初数据量小，一切正常。但随着日志积累到亿级，深分页请求开始拖垮整个链路。监控数据显示：
- 第 100 页以内：平均响应 <300ms
- 第 1000 页：>2s
- 第 5000 页以上：普遍超过 6s，偶尔触发 OOM
深入排查发现，协调节点成为最大受害者。每次 deep paging 请求到来时，它都要从每个 shard 拉取(from + size)条记录做归并排序，哪怕最终只返回几条结果。
比如from=5000, size=10，假设 5 个主分片，协调节点就要先拿到 5×5010 = 25050 条中间数据，再排序截取。这些临时对象大量驻留堆内存，频繁引发 Full GC。
📌 核心结论：
from + size的代价不是线性增长，而是随from值指数上升。官方默认限制index.max_result_window=10000不是随便设的。
于是我们意识到：必须换掉这套机制。
二、三种分页方案的真实对比：不只是 API 差异
要解决问题，先得搞懂工具有哪些，各自适合什么场景。我们重新梳理了 Elasticsearch 提供的三大分页能力。
1. from + size：简单但脆弱
{ "from": 5000, "size": 10, "query": { ... }, "sort": [ { "@timestamp": "desc" } ] }优点不用多说：支持任意跳页，前端对接方便，开发成本低。
但它的底层机制决定了无法胜任深分页任务：
- 每次请求都会重新执行完整搜索。
- 协调节点需加载所有前置数据进行排序合并。
- 数据越多，merge 成本越高，极易压垮协调节点。
📌适用边界：建议仅用于from + size ≤ 10,000的浅层翻页。超出部分应引导用户缩小时间范围或启用“加载更多”模式。
2. Scroll API：全量扫描利器，而非实时分页工具
Scroll 的设计初衷根本就不是做网页翻页，而是像数据库游标一样遍历海量数据，常用于：
- 日志导出
- 数据迁移
- 批量分析任务
它的工作流程如下：
- 发起带
scroll="1m"参数的初始查询； - ES 创建搜索上下文（Search Context），保存当前索引快照；
- 返回第一批结果和
_scroll_id； - 客户端用
_scroll_id轮询拉取下一批； - 结束后主动清除上下文释放资源。
下面是 Java 中使用RestHighLevelClient的关键实现：
SearchRequest request = new SearchRequest("logs-*"); SearchSourceBuilder source = new SearchSourceBuilder(); source.query(QueryBuilders.rangeQuery("@timestamp").gte("now-7d")); source.size(1000); source.sort("@timestamp", SortOrder.ASC); request.source(source); request.scroll(TimeValue.timeValueMinutes(1)); SearchResponse firstResp = client.search(request, RequestOptions.DEFAULT); String scrollId = firstResp.getScrollId(); while (true) { // 处理当前批次 Arrays.stream(firstResp.getHits().getHits()) .forEach(hit -> processLog(hit.getSourceAsString())); // 获取下一批 ScrollRequest scrollReq = new ScrollRequest(scrollId); scrollReq.scroll(TimeValue.timeValueMinutes(1)); SearchResponse nextResp = client.scroll(scrollReq, RequestOptions.DEFAULT); if (nextResp.getHits().getHits().length == 0) break; scrollId = nextResp.getScrollId(); firstResp = nextResp; } // 必须手动清理！否则内存泄漏 ClearScrollRequest clearReq = new ClearScrollRequest(); clearReq.addScrollId(scrollId); client.clearScroll(clearReq, RequestOptions.DEFAULT);⚠️ 使用注意点：
- 不能反映实时变更：基于 Lucene 快照，中途写入的数据不会出现在后续批次中。
- 资源占用高：每个活跃的 scroll 上下文都会占用 JVM 堆内存。
- 必须及时清理：忘记调用
clear_scroll会导致内存持续累积，最终拖垮节点。
所以，Scroll 更适合后台异步任务，比如点击“导出全部”按钮后启动一个独立 Job 去拉数据写入 S3。
3. search_after：现代分页的正确打开方式
如果你需要构建一个高性能、可伸缩的实时查询接口，search_after才是你该首选的方案。
它不再依赖偏移量，而是通过上一页最后一个文档的排序值来定位下一页起点。
举个例子：
你想按时间倒序查日志，当前页最后一条记录的时间戳是T=1680000000，ID 是abc123。
那么下一页查询只需加上：
{ "size": 10, "query": { ... }, "sort": [ { "@timestamp": "desc" }, { "_id": "asc" } ], "search_after": [1680000000, "abc123"] }ES 会自动跳过等于该排序值的文档，返回之后的结果。
✅ 优势非常明显：
- 性能恒定：无论翻多少页，每次都是精准定位，无 merge 开销。
- 支持实时更新：每次查询都基于最新数据状态。
- 内存友好：无需维护上下文，轻量高效。
❌ 缺陷也很明确：
- 不支持跳页：只能一页一页往下翻。
- 排序字段必须唯一：若只按时间排序，同一秒内多条日志可能乱序或漏数据。
🔧 解决方案：组合排序字段！
推荐使用"@timestamp" + "_id"组合，既能保证全局有序，又能避免重复值导致的分页错位。
下面是一个 Python 示例（使用elasticsearch-py）：
def fetch_logs_with_search_after(es_client, index, page_size=500): query = { "size": page_size, "query": {"match_all": {}}, "sort": [ {"@timestamp": {"order": "desc"}}, {"_id": {"order": "asc"}} # 补充唯一性 ] } results_count = 0 last_sort_values = None while True: if last_sort_values: query["search_after"] = last_sort_values resp = es_client.search(index=index, body=query) hits = resp["hits"]["hits"] if not hits: break for hit in hits: print(f"[{hit['_source']['@timestamp']}] {hit['_id']}") results_count += 1 last_sort_values = hit["sort"] # 记录最后一条的排序值 print(f"已处理 {results_count} 条")这个模式特别适合移动端“无限滚动”、管理后台“查看更多”等连续加载场景。
三、落地策略：如何让优化真正跑起来？
理论清晰了，接下来是如何在真实系统中平稳过渡。
我们的改造路径
前端限制 + 引导
- 将普通分页的最大页码锁定在 100 页以内（即最多展示 1000 条）；
- 超出提示：“数据过多，请调整时间范围”；
- 对于“查看更早日志”需求，提供“加载更早”按钮，背后走search_after流程。API 层拆分职责
-/api/logs?page=10→ 使用from+size，限流保护；
-/api/logs/next?after_time=xxx&after_id=yyy→ 使用search_after，支持深层拉取；
-/api/logs/export→ 后台启动 Scroll 任务，异步生成下载链接。排序字段标准化
- 所有涉及分页的查询强制指定双排序字段：json "sort": [ { "@timestamp": "desc" }, { "_id": "asc" } ]
- 若业务主键更稳定（如 trace_id），也可替换_id字段。Scroll 生命周期管控
- 设置合理超时：一般设为1~5m，避免长时间驻留；
- 加入失败重试：网络抖动导致scroll_id失效时，自动重建初始查询；
- 监控未清理上下文数量，设置告警阈值。批大小调优
- 单次拉取不宜过大（建议 500~1000 条）；
- 过大会增加单次响应时间和内存压力；
- 过小则 RPC 次数增多，影响吞吐。
四、效果验证：数字不会说谎
优化上线一周后，核心指标显著改善：
| 指标 | 优化前 | 优化后 | 提升幅度 |
|---|---|---|---|
| 平均分页响应时间 | 1.8s | 240ms | ↓ 87% |
| 协调节点 CPU 使用率 | 78%±15% | 27%±8% | ↓ 65% |
| Full GC 频次（每小时） | 12~18 次 | 1~3 次 | ↓ 80%+ |
| 最大可查页数 | ~1000 页 | 无限（通过 search_after） | ✅ 突破限制 |
更重要的是，系统稳定性大幅提升。即使面对突发查询高峰，也能平稳应对。
五、延伸思考：未来还能怎么走？
虽然search_after已经非常优秀，但在某些极端场景仍有局限。例如：
- 需要长时间遍历数十亿数据？
- 希望在整个过程中保持一致视图，同时又不想用 Scroll？
这时候可以考虑PIT（Point In Time）—— ES 7.10+ 引入的新特性。
PIT 允许你在某个时刻打开一个“时间点快照”，后续查询均可基于此快照执行，无需维持 search context。结合search_after，即可实现：
- 实时性可控的一致视图；
- 无内存泄漏风险；
- 支持超长时间遍历。
示例请求：
POST /logs/_pit?keep_alive=1m {}返回id后，在查询中引用：
{ "size": 1000, "query": { ... }, "sort": [ ... ], "search_after": [...], "pit": { "id": "...", "keep_alive": "1m" } }相比 Scroll，PIT 更安全、更灵活，是未来替代 Scroll 的理想选择。
写在最后
这次优化让我深刻体会到：工具没有好坏之分，只有是否用对场景。
from + size并非“落后”，它是轻量级交互的最佳选择；- Scroll 也不是“淘汰”，它仍是大数据批量处理的王者；
search_after的出现，填补了“高并发实时深分页”的空白。
作为开发者，我们要做的，是在合适的时机调用合适的 API，把资源消耗降到最低，把用户体验提到最高。
如果你也在用es客户端做分页查询，不妨回头看看：
你的 deep paging 是怎么处理的？
有没有还在用from=10000硬扛？
Scroll 任务结束后是否清掉了上下文？
一个小改动，可能就能换来整个系统的呼吸空间。
欢迎在评论区分享你的实践经验，我们一起把 ES 用得更稳、更快。
