Elasticsearch scroll超时如何实现无数据拉取的保活续期

ES 7.17 原生支持针对指定scrollId发送不实际拉取业务数据的保活请求，完全可以满足前端自动续期、不额外占用不必要资源的需求。

调用_search/scroll端点时，传入目标scrollId、需要续期的时长，同时将size参数设为0即可。该请求只会刷新对应scroll上下文的过期时间，不会执行实际数据检索、不会推进游标位置，返回结果中不会携带业务数据，资源开销极低。
请求示例：

POST /_search/scroll
{
  "scroll": "2m",
  "scroll_id": "当前会话持有的scrollId",
  "size": 0
}

注意：保活请求的有效期从请求发起时刻开始重新计算，不会影响后续正式拉取的数据位置，下一次带正常size参数的拉取请求，会从上次中断的位置继续返回数据，不会出现漏数、重复问题。

• 给scroll会话设置合理的基础超时（比如2分钟），前端在会话存活期间启动兜底定时器：间隔时长比超时时长短20%左右（比如1分40秒）检测一次，只要当前滚动会话未被主动销毁（用户未离开列表页、未重置搜索条件），就自动发起保活请求。
• 绑定页面可见性事件：用户切到其他标签页、最小化窗口时暂停保活定时器，避免无意义的请求；用户切回页面时先判断距离上次请求（拉数/保活）的间隔，未超过超时时间则发一次保活续期，已超过超时时间则直接重新初始化查询，避免续期失效。
• 增加主动销毁逻辑：用户离开列表、重置搜索条件、主动终止查询时，立刻调用DELETE /_search/scroll接口传入对应scrollId手动释放上下文，无需等待超时自动回收，进一步降低集群内存占用。

如果不想维护scroll上下文的保活逻辑，可以选择更适配前端无限滚动场景的方案：

• 优先选用search_after分页：这是ES官方面向用户端实时分页推荐的方案，没有服务端常驻的scroll上下文，完全不存在超时问题，每次请求携带上一页最后一条数据的排序值即可拉取下一批数据，内存开销远低于scroll。使用时需要将唯一不重复的字段（比如文档_id）作为第二排序键，避免排序值重复导致的分页漏数、重复问题。
• 数据量不大的场景可以直接用from + size普通分页：配合前端缓存已加载的页面数据，逻辑实现最简单，也没有上下文维护成本，注意设置合理的分页深度上限即可。

内容的提问来源于stack exchange，提问作者VeryNiceArgumentException