假如我来设计scroll－Elasticsearch的遍历操作分析

静下心来仔细想想之后，发现要实现这个其实也并不复杂，我甚至想起曾经在一个搜索结果merge需求中自己设计过的方法。

假设有n个搜索结果集（ResultSet），每个结果集均按照score字段排序，要求：

1. 从n个结果集中取出m个结果合并为一个结果集（m与n无固定关系）

2. n个结果集中的数据必须至少有一条包含在最终结果中

3. 任意结果集中按照score大小顺序取值

4. 结果合并必须支持分页

（如图为需要合并的结果集）

方案设计其实也很简单，因为结果集中的数据都是有序的，首页的结果只要循环按顺序从n个结果集中取一条数据合并就可以满足；再抽象一下，根据这种固定模式，通过任意一次请求的from来计算每个结果集的偏移量offset，从每个结果集的第offset+1个结果开始顺序取结果就能满足如上要求了。

（按图示，RS0～4依次循环取doc合并即可得到最终结果，

其中RS0的下一次请求偏移量为2，其余均为1）

代码实现还是比较简短的，首先是计算每个分片（shard）内的请求需要的偏移量（newfrom）和返回结果数（newsize）：

private void procOffset(int from, int size, int shards) {
    // 演示计算，newfrom／newsize表示最终计算得到的每个分片的偏移量
    int[] newfrom = new int[shards];
    int[] newsize = new int[shards];
    for (int i = 0; i < newfrom.length; i++) {
        newfrom[i] = 0;
    }
    for (int i = 0; i < newsize.length; i++) {
        newsize[i] = 0;
    }
    while (from > 0 || size > 0) {
        for (int i = 0; i < shards; i++) {
            // 计算每个分片的偏移量
            if (from > 0) {
                // 先处理from偏移
                newfrom[i]++;
                from--;
            } else {
                // from偏移处理完成后再处理size,保证size偏移的起点紧接于from偏移的终点
                newsize[i]++;
                size--;
            }
            if (from == 0 && size == 0) {
                break;
            }
        }
    }
}

然后是取得结果后的结果合并操作：

// Item表示每个shard返回的结果集，Hit表示单结果
private QuerySerDer mergeResult(Item[] items) {
    List<Hit> results = new LinkedList<>();
    // 表示遍历子查询结果的数组位置，一轮变一次
    int index = 0;
    boolean hasNext;
    for (; ; ) {
        hasNext = false;
        for (Item item : items) {
            if (item.isFailure()) {
                // 子查询失败，跳过
                continue;
            }
            if (null == item.getHits() || item.getHits().length == 0) {
                // 如果子查询没有结果，跳入下一个子查询
                continue;
            }
            if (item.getHits().length <= index) {
                // 如果子查询的长度不足（总长度小于本轮偏移量），进入下一个子查询结果
                continue;
            }
            hasNext = true;
            Hit hit = item.getHits()[index];
            results.add(hit);
        }
        if (!hasNext) {
            break;
        }
        // 全部子查询遍历之后偏移量＋1
        index++;
    }

    return results;
}

实现了上面四点要求就已经可以满足scroll按需返回size条记录了。 

到这里，我们回来看看scroll请求的前提条件：

1. 记录每次请求的上下文

2. 保证遍历的数据稳定不变

每次scroll请求都需要知道上次请求停止的点（偏移量），所以上下文是必须要记录的。一般情况下，索引数据是在不断变更过程中的，也就是scroll过程其实是伴随着数据的增删改操作的，如果以这种状态去根据上下文取数据，很有可能就会发生数据丢失的情况：

（如图所示，假设数据可变，如果两次请求间第2条数据被删除，

那么第2次请求带上偏移量5的上下文就会导致第6条数据在本次遍历中被跳过）

scroll其实遍历的是索引接收到scroll请求当时的一个快照（snapshot）数据，一个快照对应一个search context，如果context不关闭，searcher已经打开的段文件（segment）是无法删除的，即使这个段文件因为后台的段合并过程而已经变成了废弃状态。因此scroll是限定了一个过期时间（expiry time）的，就是为了保证废弃段文件能够被及时删除，避免过多的段文件导致操作系统文件句柄耗尽。

理论上通过scroll上下文，是可以做到往回翻页的（偏移量回退size个），个人感觉原因之一也是为了保证snapshot数据及时过期吧，毕竟单向翻页可以预期到过程结束，如果是双向翻页就不一定能那么快结束了。 

shard内部排序

—

从分片内查询结果并排序后，才能进行下一步的结果集合并，影响scroll取数性能表现的基础就是分片内的查询效率。

上面说到_doc，虽然外部无法感知而且每次索引写操作后_doc都会发变化，但是在一个快照（snapshot）时间内，索引文档可以认为是维持不变的，所以_doc可以保证文档顺序，就可以保证多次scroll请求之间不会拉取重复数据。

细说这个_doc，我们知道索引文档在索引文件内部是按顺序排列的，_doc其实就是索引文件内部索引文档的排列顺序，在分片内部执行constant_score查询（匹配分恒等于1）后的结果顺序天然就是按照_doc排序的，所以_doc排序请求连分片内部的排序步骤也省去了，真是做到了极致。

相对的，有序scroll在分片内部执行查询时，虽然查询步骤相同，但是还需要增加一个按指定字段重排序的步骤，相应的取数效率就低了一些。 

性能建议

—

在Es中创建索引都是可以配置分片（shard）个数的，合理的配置分片数量是保证索引查询性能的关键因素之一，过多的shard数会导致merge的结果集数量过多，导致merge效率降低；而过少的shard虽然不影响merge效率，但是在索引数据量很大的情况下，会导致单shard内文档数量过多，会因为字段缓存（体积太大）和中间结果合并（单位条件命中的倒排结果集过大，影响取交性能）等因素影响分片内查询性能，也就拖慢了整体的查询响应。

另外合理的size设置也是需要考虑的一个方面，过大的size导致过重的io操作，容易变成慢查询，过小的size设置又会带来过多的网络传输开销，一般建议size设置在100～1000之间，相信Es应该也有默认的范围限制过大的size。

当然通过上面的分析，能通过无序scroll遍历数据就通过无序scroll操作也是提高性能表现的好手段。 

结语

—

至此对Es的scroll操作分析结束，本想翻些源码来印证，然而只翻到结果合并部分代码，所以不敢妄言Es的scroll设计就是如此，不过我想应该也大概如此吧，如果有熟悉Es源码的高手，还请不吝赐教。 

欢迎大家长按关注跳跳爸的微信公众号：