作者vivo 互联网服务器团队- Chen Yifan本文介绍了一种基于 search_after Redis 多级锚点缓存的 Elasticsearch 深度分页跳页方案。针对 Elasticsearch 原生不支持随机跳页的限制通过三轮优化——分段预热缓存、最近锚点定位 Elasticsearch 查询提速禁用 _source/关闭 track_total_hits、大区间预热 小分页精细锚点——将 50 万数据量下的任意跳页响应时间从 10 分钟级优化至 1 秒以内。1 分钟看图掌握核心要点一、背景悟空活动系统目前支撑了一系列大型的摄影比赛活动在赛事评审环节管理后台需要对数十万级参赛作品进行集中展示、筛选与评审尤其在筛选环节涉及到对作品进行多维度条件筛选评审等级、作者信息、拍摄单元等。该业务场景本质上是一个“高数据量 多维组合筛选 深度分页”的后台检索系统。后台页面列表查询最初通过 MySQL 多表关联查询实现。随着赛事规模逐年扩大参赛作品量级持续攀升列表查询需要关联多张业务表并进行复杂条件筛选。在数据规模和并发请求不断增长的情况下MySQL 查询逐渐暴露出以下问题多表关联查询复杂SQL 执行成本较高数据量持续增长查询耗时明显上升高并发场景下数据库压力较大影响系统整体稳定性。为降低数据库查询压力并提升检索性能我们对系统进行了重构优化将原有的 MySQL 列表查询逻辑迁移至 Elasticsearch利用 Elasticsearch 在大规模数据检索与多维条件组合过滤方面的优势来承载后台的页面查询能力。在实际业务场景中用户可能会在评审结束以及评审过程中进行随机跳页查询来查看评审数据以及作品信息。但是 Elasticsearch 自身目前的查询能力只提供了用于顺序翻找的 scroll API 以及 search after无法直接跳转至任意页。为了不影响用户的使用体验因此进行 Elasticsearch 深度分页的优化。二、基础方案选择目前 Elasticsearch 所提供的深度查询的方案主要有三种fromsize、scroll API 以及 search after。对于用户点击深度分页的场景Elasticsearch 官方更推荐使用 search after。而 scroll API 则更适合应用于后台大规模数据扫描的应用场景来对整批索引数据进行稳定地的遍历查询。为了直观对比三种方案的流程和优劣我们绘制了以下的流程图。如图所示方案一有着最大数量的限制方案二会占用大量的 Elasticsearch 内存给集群造成压力。最终我们选择方案三相对于方案一该方案不需要计算大量的偏移数据而相比于方案二该方案采用无状态查询方式不需要在 Elasticsearch 节点上维护额外的查询上下文更适合用户的在线查询场景。三、跳页解决方案演进3.1 阶段一基础方案在确定使用 search_after 作为深度分页的基础查询方式后我们首先实现了一套基于 缓存 search_after 的分页方案用于在一定程度上支持用户的深度分页查询。由于 search_after 只能基于上一页的排序位置进行顺序翻页而无法直接跳转至任意分页位置因此需要通过额外的缓存机制记录部分分页位置对应的 search_after 值从而减少顺序查询的次数。在该阶段的方案中我们设计了一种分段预热的缓存策略。异步预热当用户首次进入列表页面进行查询时系统会启动一个异步线程在后台按照 1000 条数据为一个步长对查询结果进行预热处理。多粒度缓存在每个步长位置系统会继续按照当前系统预设的分页大小10、20、50、100分别记录当前查询结果最后一条数据对应的 sortValues。Redis 存储将该数据的位置和对应的 sortValues 缓存到 Redis 的 hash 结构中。当用户访问的分页位置超过 Elasticsearch 默认的深度分页限制10000之后系统会根据用户当前的分页大小计算出当前页面的开始位置from并从 10000 对应的缓存锚点位置重新开始执行 search_after 查询并按照用户当前查询的分页大小顺序向后推进。直到命中目标位置from。之后再进行一次 search_after 查询查询出当前页面的全部数据。同时在推进过程中系统会继续补充新的 search_after 锚点缓存以逐步完善缓存中的分页位置数据。该方案在命中缓存时会根据当前缓存的 search_after 值再进行一次 search_after 查出指定页面的相对数据查询效率相对较快在 1 秒钟内能够返回结果。然而该方案在实际运行过程中仍然存在一定局限性当用户第一次访问某个较深的分页位置时由于缓存尚未完全构建系统仍然需要执行大量顺序 search_after 查询锚点缓存依赖于预热过程若用户访问的分页区间分布较为随机缓存命中率可能较低在极端情况下用户直接跳转到较深的分页位置时查询延迟仍然较高。如下图所示对于八十万级的数据量级用户第一次进去直接跳转最后一页需要十分钟左右的预热时间。3.2 阶段二性能优化3.2.1 优化点一引入最近锚点定位在阶段一的方案中系统通过缓存部分 search_after 游标来辅助深度分页查询在一定程度上缓解了顺序翻页带来的性能问题。然而该方案仍然存在一个明显的不足当用户直接跳转到较深的分页位置时如果目标页附近没有可用的缓存游标系统仍然需要执行较多次顺序 search_after 查询导致查询耗时较长。我们认为既然已经在用户第一次访问时做了缓存预热的操作那在后续的操作中我们也想尽可能地最大程度地利用已经缓存的锚点提高查询效率。那么很容易就可以想到在用户每次的查询过程中找到距离当前数据最近的一次 searchAfter 记录并根据该记录动态计算出和目标页面所相差的数据条数再进行一次 searchAfter 操作来跳到目标页数。为了实现该想法我们引入了 Redis ZSet 作为偏移量索引。不再生硬地从头扫描而是在数据链路上钉上“锚点”。1.动态锚点预热步长机制用户首次进入时系统以 1000 条为步长自动向后预热。缓存结构将查询位置存为 score将 Elasticsearch 的 sortValues 存为 value维护在 Redis ZSet 中。2. “跳板式”精准命中坐标换算根据 pageNum * pageSize 计算目标位置 from。快速定位利用 ZSet 的 reverseRangeBy-Score 命令毫秒级锁定小于且最接近目标位置的那个“锚点”。区间收缩将原本几十万量级的扫描瞬间收缩到 1000 条以内的微小区间。3. 远程跳跃保护设置最大缓存间隔。若最近锚点距离目标过远系统先进行大区间的预热构建快速逼近目标区间后再切换到小步长精确命中。详细流程如下图所示效果同等数据量下跳到最后一页的时间从 10 分钟降到约 6 分钟预热完成后任意跳页约 3 秒。有进步但还不够。3.2.2 优化点二优化 Elasticsearch 查询效率目前来说最耗时的部分还是在于缓存的预热和大幅度跳页之后根据就近锚点深度查找的过程中的 Elasticsearch 查找操作对于五十万级别的数据量级按照 1000 的步长进行搜索构造需要在预热过程中进行 500 次查询操作如果每次的查询时间耗时较长总和加起来耗时会非常庞大。而预热阶段我们根本不需要完整的文档数据只需要 sortValues。于是我们做了两个关键调整1禁用_source 字段Elasticsearch 查询默认会返回完整的 _source 文档内容这涉及大量磁盘 I/O 和反序列化开销。在预热阶段我们只需要排序值完全可以通过_source: false 跳过文档内容的读取。2关闭 track_total_hitsElasticsearch 查询默认会计算匹配文档的总数total_hits这需要扫描所有匹配文档。在 search_after 预热场景中我们并不关心总数关闭后可以省去这部分开销。下图是未禁用相关参数的耗时而下图则是在禁用_source 以及关闭掉 track_total_hits 之后的同等耗时每次查询大概在 500ms 左右相较于默认查询耗时有了显著减少。此外在查询开销降低后我们进一步调整了分页预热的步长策略。相比于原先较小的分页步长在减少返回数据量的前提下可以适当增大每次查询获取的数据量从而减少与 Elasticsearch 的交互次数提高整体预热效率。经过多次测试与调优后我们将预热步长调整为 5000 条数据。在该配置下系统在用户首次跳转至最后一页时整体查询时间已经能够稳定控制在一分钟以内相比初始方案有了明显提升。但在实际使用过程中如果用户直接跳转至任意较深的分页位置系统仍然需要通过已有锚点执行少量 search_after 顺序推进查询因此整体查询耗时仍可能达到 1 秒以上。因此当前方案在随机跳页场景下仍然存在进一步优化的空间。3.2.3 优化点三分割预热区间第二版解决了预热速度的问题但仍然有一个痛点预热后跳页仍需约 1 秒。原因是锚点粒度仍然是 5000用户请求的页码大概率不会刚好落在锚点上还需要做一段距离的顺序推进。因此我们进一步思考如果我们能把锚点粒度做到和最小分页大小一致比如 10 条那用户跳到任何页都能直接命中缓存只需要一次 search_after 查询就能拿到结果。为了实现这个构想同时又不拖慢主预热链路我们设计了一套“大区间同步 小区间异步”的分层架构系统维持原有的逻辑以 5000 条数据为一个大区间进行预热查询确保主进度的覆盖。在获取到大区间数据后后台同步启动一个异步线程,以最小分页大小如 pageSize 10为基础单位,将 5000 条的大结果集切割成 500 个细小的分页区间并构建缓存。当用户发起跳页请求时会直接定位到该页码对应的细粒度锚点。取出对应的 search_after 值。最终的流程如下图所示通过这种“大区间预热 小分页锚点缓存”的策略系统在保证缓存覆盖范围的同时将随机跳页场景下的顺序查询次数降至最低从而有效提升了深度分页查询的响应速度并进一步提高了缓存命中率。在测试环境的实际测试中可以发现对于七十万级的数据量级预热完成后随机点击页面的 RT 也基本能够保证在 1s 以内。线上模拟的五十万级数据级别的响应时间也都在理想范围内四、目前问题在上述优化方案中为了减少深度分页时的顺序查询次数我们通过 Redis 对 search_after 锚点进行了缓存从而在用户跳页时能够快速定位到接近目标位置的数据区间。然而在实际运行过程中也暴露出了一个新的问题数据漂移具体表现为新数据写入后原来最后一页的锚点可能不再是真正的尾部跳到最后一页可能返回空页数据删除后某些锚点对应的位置可能出现数据重复或缺失。该问题产生的根本原因在于 Elasticsearch 索引数据与 Redis 中缓存的分页锚点之间并非强一致关系。在当前方案中分页锚点是在预热阶段通过查询 Elasticsearch 生成并缓存到 Redis 中的这些锚点本质上记录的是某一时刻 Elasticsearch 索引数据在特定排序条件下的位置。当上述情况发生时Elasticsearch 中的真实数据顺序可能已经发生变化而 Redis 中缓存的锚点仍然对应的是旧的数据位置。此时当系统使用 Redis 中的锚点作为 search_after 的起点继续执行查询时实际的分页起始位置就可能与用户期望的分页位置产生偏差从而出现数据漂移现象。应对策略该方案本质上更适用于数据相对稳定的查询场景——在我们的业务中深度分页的使用高峰主要在数据趋于稳定的后期阶段数据大量变化的概率较小对于可能出现的空页问题系统会清除缓存并基于最新的 Elasticsearch 数据重新预热如果你的场景中数据变更非常频繁可能需要考虑其他方案如基于时间戳或版本号的增量更新策略。五、思考回顾整个优化过程核心思路可以提炼为这次优化的过程本质上不只是一次 Elasticsearch 性能调优更是一次面对多目标约束时如何拆解问题、逐步逼近最优解的工程实践。希望这些经验对遇到类似问题的同学有所帮助。
