ES 游标过期时间设置引发的连环惨案

scroll 查询

scroll 查询可以有效地从 ES 中单个检索中获取大量的结果，类似于数据库中的 cursor。scroll 查询可以获取时间点的快照数据。每次请求会将查询到的 id 列表保留在一个 context 中，即记一个游标 scroll_id。

问题还原

问题一

用户侧反馈，对 ES 做游标分页查询得时候发现返回很多重复的数据，影响用户消息推送。并且出现重复数据的现象无法复现，频率也较低，大概2天一次。

问题二

用户侧反馈监控到查询结果延迟较高，集群健康值为黄色。

查看集群日志，发现有大量的报错，报错信息表示存放的 scroll_id 超出了默认的500限制。

trying to creat too many scroll aontexts。Must be less than or equal to: [500].This limit can be set by changing the [search.max_open_scroll_context] setting.

问题排查

1、根据这个报错，首先采取了临时解决方案，调大 search.max_open_scroll_context 参数；

curl GET http://x.x.x.x:9200/_cluster/settings

"persistent" : {
        "search.max_open_scroll_context": 1024
    },
    "transient": {
        "search.max_open_scroll_context": 1024
    }
}'

2、调整后观察集群，日志报错已没有了，但请求延迟的情况依然存在；

3、查看集群状态，健康状态为黄色，主要是因为分片分配不均，集群会主动进行负载均衡，副本搬迁过程中可能会有副本不可用的情况，导致集群变黄。

于是手动将分片数调整为节点的整数倍，分片分配完成后集群健康值变绿，但延迟情况依然存在。

4、用户提供了执行查询的语句

POST /user_portrait/_search?scroll=5m
{
  "query": {
    "bool": {"must": [
      {"bool": {"filter": {"range": {
        "assets_level": {
          "gt": 1
        }
      }}}},
      {"bool": {"filter": {"range": {
        "last_login_date": {
          "gt": 0
        }
      }}}}
    ]}
  },
  "_source": "{_id}",
  "size":10000
}

通过这条语句，发现用户将 scroll 的时间设置成了5m，这表示执行这条语句时要将此游标保持开启5分钟，这个值的时间不必 cover 处理所有数据，只要够处理前一次的结果的数据就行。因此这个值的时间不能设置太长。这就是导致两个问题的原因。

问题总结

1、虽然进行 scroll 查询时会记录一个 scroll_id，但只有新请求时才会生成新的 scroll_id，这就有一定概率导致查询到的返回结果出现重复数据的可能。

2、scroll 开启时间过长，导致 scroll_id 的清除时间太久产生堆积，所以引起了数据查询延迟。

最终解决

用户的查询是无状态的，不会保存之前使用过的 scroll_id，所以需要在一次查询结束后清除最后一次请求的 scroll_id。因此建议用户将此值改为2m。修改完成后以上两个问题都已解决。