实习成长之路：关于ElasticSearch深度分页带来的思考，如何解决深度分页和跳页

问题引入

我们在平常使用ElasticSearch构建查询条件的时候一般用的都是from+size的方式进行分页查询，但是如果我们的页数太深/页面大小太大(from*size)>10000就会引发一个错误，我们将会得到一个错误

这是为什么呢？
因为ES的分页查询其实是这样来的
因为ElasticSeach的天生分布式的原因，我们的数据是分散在几个分片中的，而我们设置了from+size需要对全部数据进行查询，ES就以下面这种方式进行了查询

Query阶段

1. Client 发送一次搜索请求，node1 接收到请求，然后，node1 创建一个大小为 from + size的优先级队列用来存结果，我们管 node1 叫 coordinating node。
2. coordinating node将请求广播到涉及到的 shards，每个 shard 在内部执行搜索请求，然后，将结果存到内部的大小同样为 from + size 的优先级队列里，可以把优先级队列理解为一个包含 top N结果的列表。
3. 每个 shard 把暂存在自身优先级队列里的数据返回给 coordinating node，coordinating node 拿到各个 shards 返回的结果后对结果进行一次合并，产生一个全局的优先级队列，存到自身的优先级队列里。

在上面的例子中，coordinating node 拿到(from + size) * 6条数据，然后合并并排序后选择前面的from + size条数据存到优先级队列，以便 fetch 阶段使用。

Fetch阶段

query 阶段知道了要取哪些数据，但是并没有取具体的数据，这就是 fetch 阶段要做的。

1. coordinating node 发送 GET 请求到相关shards。

2. shard 根据 doc 的 _id取到数据详情，然后返回给 coordinating node。

3. coordinating node 返回数据给 Client。

coordinating node 的优先级队列里有from + size 个_doc _id，但是，在 fetch 阶段，并不需要取回所有数据，在上面的例子中，前100条数据是不需要取的，只需要取优先级队列里的第101到110条数据即可。

需要取的数据可能在不同分片，也可能在同一分片，coordinating node 使用 「multi-get」来避免多次去同一分片取数据，从而提高性能。

这种方式请求深度分页是有问题的：

我们可以假设在一个有 5 个主分片的索引中搜索。当我们请求结果的第一页（结果从 1 到 10 ），每一个分片产生前 10 的结果，并且返回给 协调节点，协调节点对 50 个结果排序得到全部结果的前 10 个。

现在假设我们请求第 1000 页—结果从 10001 到 10010 。所有都以相同的方式工作除了每个分片不得不产生前10010个结果以外。然后协调节点对全部 50050 个结果排序最后丢弃掉这些结果中的 50040 个结果。

对结果排序的成本随分页的深度成指数上升。

如何解决深度分页

分页方式 scorll

es 提供了 scroll 的方式进行分页读取。原理上是对某次查询生成一个游标 scroll_id ， 后续的查询只需要根据这个游标去取数据，直到结果集中返回的 hits 字段为空，就表示遍历结束。scroll_id 的生成可以理解为建立了一个临时的历史快照，在此之后的增删改查等