Elasticsearch系列---搜索执行过程及scroll游标查询

概要

本篇主要介绍一下分布式环境中搜索的两阶段执行过程。

两阶段搜索过程

回顾我们之前的CRUD操作，因为只对单个文档进行处理，文档的唯一性很容易确定，并且很容易知道是此文档在哪个node，哪个shard中。

但搜索比CRUD复杂，符合搜索条件的文档，可能散落在各个node、各个shard中，我们需要找到匹配的文档，并且把从各个node，各个shard返回的结果进行汇总、排序，组成一个最终的结果排序列表，才算完成一个搜索过程。我们将按两阶段的方式对这个过程进行讲解。

查询阶段

假定我们的ES集群有三个node，numberofprimary_shards为3，replica shard为1，我们执行一个这样的查询请求：

GET /music/children/_search
{
  "from": 980,
  "size": 20
}

查询阶段的过程示意图如下：

1. Java客户端发起查询请求，接受请求的node-1成为Coordinate Node（协调者），该node会创建一个priority queue，长度为from size即1000。
2. Coordinate Node将请求分发到所有的primary shard或replica shard中，每个shard在本地创建一个同样大小的priority queue，长度也为from size，用于存储该shard执行查询的结果。
3. 每个shard将各自priority queue的元素返回给Coordinate Node，元素内只包含文档的ID和排序值（如_score），Coordinate Node将合并所有的元素到自己的priority queue中，并完成排序动作，最终根据from、size值对结果进行截取。

补充说明：

1. 哪个node接收客户端的请求，该node就会成为Coordinate Node。
2. Coordinate Node转发请求时，会根据负载均衡算法分配到同一分片的primary shard或replica shard上，为什么说replica值设置得大一些可以增加系统吞吐量的原理就在这里，Coordinate Node的查询请求负载均衡算法会轮询所有的可用shard，并发场景时就会有更多的硬件资源（CPU、内存，IO）会参与其中，系统整体的吞吐量就能提升。
3. 此查询过程Coordinate Node得到是轻量级的元素信息&#