本文我们结合官网一起聊聊Elasticsearch 读取流程（Search）的读取流程，我们在本篇不分一个文档还是多个文档。

读取流程（Search）

我画了一个草图，大概能够清晰的说明问题大家可以参考

读取流程

1. 客户端发起搜索请求

• 客户端发送搜索请求（如 search、get）到协调节点，请求中可指定查询条件、过滤条件、排序等参数。

2. 协调节点广播请求到相关分片

• 协调节点根据索引的分片配置，确定需要查询的分片（主分片或副本分片，优先选择负载较低的节点）。

• 对于 查询阶段（Query Phase） ，协调节点将请求广播到所有相关分片（每个分片处理自己的部分数据）。

3. 分片执行本地搜索并返回中间结果

• 每个分片在本地执行搜索，过滤出符合条件的文档，并提取文档 ID、分数（Score）等信息，形成中间结果集（不返回完整文档内容）。

• 分片将中间结果返回给协调节点，协调节点收集所有分片的结果后进行全局排序（按分数、指定字段等）。

4. 协调节点汇总结果并获取完整文档（Fetch Phase）

• 若搜索结果需要返回完整文档（如 get 请求或 search 中指定返回字段），协调节点会根据排序后的文档 ID，向对应的分片发送获取文档请求（仅获取目标文档）。

• 分片返回完整文档内容，协调节点汇总后整理成最终结果，返回给客户端。。

拆解 Elasticsearch 搜索流程

今天结合流程示意图，用三个节点（分片节点1、2、3 ）的场景，带大家理清 ES 搜索的底层逻辑。

参考官网图 https://www.elastic.co/guide/cn/elasticsearch/guide/current/distrib-multi-doc.html

一、查询阶段（Query Phase）：广撒网，捞候选

当客户端发送搜索请求（比如带查询条件、排序参数的 search/get 操作 ），流程先进入查询阶段 ：

• 请求广播：协调节点收到请求后，会把查询任务“广撒网”式地发给各个分片节点（分片节点1、2、3 ）。不管数据存在哪个分片，都要参与初步筛选，这一步像在整片海域撒网，不放过任何可能的“目标鱼”。

• 本地筛选：每个分片节点接到任务，会在自己的分片里执行搜索，过滤出符合条件的文档，只返回文档 ID、分数（用于排序等）等“精简信息”。比如分片节点1筛出一批文档，把 ID 和分数打包成“中间结果”，回传给协调节点；分片节点2、3 也同步做这件事。

• 全局排序：协调节点收集完所有分片的“中间结果”，会根据分数、排序参数等，对这些候选文档做全局排序 ，选出最符合查询需求的一批文档（比如按分数从高到低取 Top N ）。这一步，协调节点就像“总调度”，把分散的候选数据重新整合排序。

二、获取阶段（Fetch Phase）：精准捞，拿完整

经过查询阶段，协调节点已经知道该找哪些文档的完整内容了，接下来进入获取阶段：

• 请求精准发送：协调节点根据排序后的文档 ID ，向对应的分片节点发送“获取完整文档”的请求。比如某个文档 ID 对应的分片在节点2 ，协调节点就定向找节点2 要数据。

• 完整文档返回：分片节点收到请求，从自己的分片里取出完整文档内容，回传给协调节点。像节点1、2、3 各自负责的文档，都会把完整数据“交上去”。

• 结果汇总整理：协调节点收集所有完整文档后，进行最后的汇总、整理（比如按查询要求格式化数据 ），然后把最终的搜索结果返回给客户端。到这里，一场“寻数大冒险”才算落幕。

三、三个节点的协作缩影

在三个分片节点的场景里，查询阶段是“广撒网、初步筛”，每个节点都参与候选文档的筛选；获取阶段是“定向捞、拿全量”，节点按需提供完整数据。协调节点始终扮演“总指挥”，串联起整个流程，让分散在不同分片的数据，能有序整合出最终结果。

理解这套流程，当遇到搜索慢、结果异常等问题时，就能更清晰地排查：比如查询阶段某个分片响应慢，可能拖慢整体速度；获取阶段文档缺失，可能是分片数据异常。

你在使用 ES 搜索时，遇到过哪些“奇怪”的问题？是结果不对，还是速度太慢？欢迎评论区分享，一起拆解 ES（不同 ES 版本流程细节可能有差异，实际以所用版本为准）