如何避免：让同一个用户始终使用同一个shard，就可以避免这种问题，常见的做法是preference设置为sessionid或userid，如：
GET /music/children/_search?preference=10086 { "from": 980, "size": 20 } 超时问题我们回顾查询阶段和取回阶段，必须所有的操作都完成了，才给客户端返回结果，如果中途有shard在执行特别重的任务，导致查询很慢怎么办？会拖慢整个集群吗？
如果是高并发场景，那极有可能，因为某一个节点慢，整个查询请求堆积，拖死集群都有可能。
为了防止这一情况，我们使用timeout参数，告诉shard允许处理数据的最大时间，时间一到，执行关门动作，能有多少数据返回多少数据，剩下的不要了，这样可以确保集群是稳定运行的，如下图所示：
在设计大规模数据搜索时，我们为了实现数据集中性，索引时会按一定规则将数据进行存储，比如订单数据，我们会按userid为route key，每个userid的订单数据，都放在同一个shard上，既然存储时使用了route key，那么搜索时同样使用route key，可以让查询只搜索相关的shard，如：
GET /music/children/_search?routing=10086 { "from": 980, "size": 20 }这样由于精准到具体的shard，可以极大的缩小搜索范围，数据量越大，效果越明显。
搜索类型默认的搜索类型是query_then_fetch，我们还可以选择dfs_query_then_fetch，这个有预查询阶段，可以从所有相关shard中获取词频来计算全局词频，可以提升revelance sort精准度。
scroll游标查询如果我们要把大批量的数据从ES集群中取出，用来执行一些计算，一次性取完肯定不合适，IO压力过大，性能容易出问题，分页查询又容易造成deep paging的问题。一般推荐使用scroll查询，一批一批的查，直到所有数据都查询完。
原理scroll查询会先做查询初始化，然后再批量地拉取结果，有点像数据库的cursor。
scroll查询会取某个时间点的快照数据，查询初始化后索引上的数据发生了变化，快照数据还是原来的，有点像数据库的索引视图。
scroll查询用字段_doc排序，去掉了全局排序，性能比较高。
scroll查询要设置过期时间，每次搜索在这个时间内完成即可。
示例我们假定每次取10条数据，时间窗口为1秒
请求如下：
响应如下（结果有删减）：
{ "_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAABJQFkExczF1dXM3VHB1RFNpVDR4RkxPb1EAAAAAAAASUhZBMXMxdXVzN1RwdURTaVQ0eEZMT29RAAAAAAAAElMWQTFzMXV1czdUcHVEU2lUNHhGTE9vUQAAAAAAABJUFkExczF1dXM3VHB1RFNpVDR4RkxPb1EAAAAAAAASURZBMXMxdXVzN1RwdURTaVQ0eEZMT29R", "took": 2, "timed_out": false, "_shards": { "total": 5, "successful": 5, "skipped": 0, "failed": 0 }, "hits": { "total": 4, "max_score": 1, "hits": [ { "_index": "music", "_type": "children", "_id": "2", "_score": 1, "_source": { "name": "wake me, shark me", "content": "don't let me sleep too late, gonna get up brightly early in the morning", "language": "english", "length": "55", "likes": 0, "author": "John Smith" } } ] } }注意那个scroll_id，下次再查询时，只要带上这个就行了
GET /_search/scroll { "scroll": "1s", "scroll_id" : "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAABJQFkExczF1dXM3VHB1RFNpVDR4RkxPb1EAAAAAAAASUhZBMXMxdXVzN1RwdURTaVQ0eEZMT29RAAAAAAAAElMWQTFzMXV1czdUcHVEU2lUNHhGTE9vUQAAAAAAABJUFkExczF1dXM3VHB1RFNpVDR4RkxPb1EAAAAAAAASURZBMXMxdXVzN1RwdURTaVQ0eEZMT29R" }每次的查询，都把最新的scroll_id带上，直到数据查询完成为止。
scroll查询看起来像分页，但使用场景不一样，分页主要是按页展示数据，主要受众是人，scroll一批一批的获取数据，主要受众一般是数据分析的系统，是给系统用的。
性能也不同，前面我们了解后，分页查询随着页数的加深，压力越来越大，而scroll是基于_doc排序的数据处理，特别适用于大批量数据的获取分析。
本篇详细介绍了查询的两阶段过程，以及能够影响查询行为的一些参数设置，历经多个版本迭代，有些preference参数已经不用了，了解一下就行，另外介绍了bouncing results产生的原理及规避办法，最后介绍了一下大批量数据查询利器scroll的简单用法。
专注Java高并发、分布式架构，更多技术干货分享与心得，请关注公众号：Java架构社区
可以扫左边二维码添加好友，邀请你加入Java架构社区微信群共同探讨技术