单集群搜索架构回顾：索引分片、副本、查询路由与协调节点原理
在深入跨集群搜索之前，必须牢固掌握单集群内部的搜索执行路径。单集群架构是所有分布式搜索系统的基石，其核心组件包括索引分片、副本、查询路由与协调节点。理解这些要素如何协同工作，是后续理解联邦查询与跨集群搜索的前提。
3.1 索引分片：水平拆分的原子单元
索引（Index）是逻辑上的数据容器，而分片（Shard）是物理存储与计算的基本单元。每个分片本质上是一个完整的 Lucene 索引实例，负责存储索引数据的一个子集。
核心原则：分片数量在索引创建时确定，后续无法修改（除重建索引外）。分片过多或过少都会影响性能——过少导致单分片负载过高，过多则增加协调开销。
| 分片属性 | 说明 | 推荐范围 |
|---|---|---|
| 主分片（Primary Shard） | 数据写入的目标，每个分片有且仅有一个主分片 | 按节点数 × 2~3 倍估算 |
| 副本分片（Replica Shard） | 主分片的完整拷贝，提供读服务与容错 | 1~2 个副本（生产环境至少 1） |
| 分片大小 | 单个分片存储的数据量 | 20GB~50GB（建议不超过 100GB） |
3.2 副本：高可用与读扩展
副本分片是主分片的精确复制品。副本的存在解决了两个关键问题：
- 高可用性：当主分片所在节点宕机时，副本分片会被提升为新的主分片，保证数据不丢失且服务不中断。
- 读扩展：查询请求可以分发到主分片或任意副本分片上执行，从而线性提升集群的查询吞吐能力。
实践建议：副本数量并非越多越好。每增加一个副本，写入时需要同步的数据量就增加一份，写入延迟会相应上升。对于读多写少的搜索场景，副本数可设为 2~3；对于写入密集场景，副本数建议不超过 2。
3.3 查询路由与协调节点：请求的指挥中枢
当客户端发起一个搜索请求时，请求首先到达集群中的任意一个节点——该节点自动成为本次请求的协调节点（Coordinating Node）。协调节点负责执行完整的查询生命周期：
- 解析与分发：解析查询 DSL，确定需要查询哪些索引及对应的分片列表。
- 扇出（Fan-out）：将查询请求并行发送到目标分片（主分片或副本分片）所在的节点。
- 本地执行：每个数据节点上的分片独立执行查询，返回匹配的文档 ID 及评分。
- 结果归并：协调节点收集所有分片的返回结果，进行全局排序、聚合、分页等操作。
- 返回响应：将最终结果组装后返回给客户端。
3.4 分片选择策略：查询路由的核心算法
协调节点在决定将查询发送到哪个分片时，遵循特定的选择策略：
- 自适应副本选择（ARS）：优先选择响应时间最短、队列深度最浅的副本分片，实现负载均衡。
- 轮询（Round-Robin）：在同等优先级的副本之间轮流分发请求。
- 偏好本地分片：如果协调节点本身也是数据节点，优先查询本地的分片副本，减少网络开销。
常见误区：很多人认为查询请求只会发送到主分片。实际上，协调节点会随机或按策略选择主分片或任意副本分片来执行查询。这意味着副本分片越多，单个分片承担的查询压力越小，但协调节点需要维护的路由表也越大。
3.5 两阶段查询：Scatter / Gather 模型
单集群搜索采用经典的Scatter / Gather（分散/收集）两阶段模型：
| 阶段 | 执行者 | 操作 | 网络传输量 |
|---|---|---|---|
| Phase 1: Scatter | 协调节点 → 数据节点 | 分发查询请求（DSL + 参数） | 小（KB 级别） |
| Phase 2: Gather | 数据节点 → 协调节点 | 返回匹配文档的 ID、评分、排序字段 | 中（取决于匹配数） |
| Phase 2b: Fetch（可选） | 协调节点 → 数据节点 | 根据文档 ID 拉取完整文档内容 | 大（取决于文档大小） |
这种模型的关键优势在于：数据本地性——每个分片只处理自己持有的数据子集，计算任务被均匀分散到所有节点上，协调节点只负责轻量级的元数据操作与结果归并。
3.6 关键性能指标与瓶颈分析
理解单集群搜索架构后，需要关注以下性能指标，它们也是后续跨集群搜索优化的核心参考：
- 协调节点 CPU 使用率：结果归并、全局排序是 CPU 密集型操作，高并发场景下协调节点可能成为瓶颈。
- 网络带宽：Gather 阶段的数据传输量直接受限于网络带宽，尤其是当查询返回大量文档 ID 或需要 Fetch 阶段时。
- 分片数量与查询延迟：分片越多，协调节点需要等待的并行查询结果越多，最慢的分片（长尾延迟）决定了整体查询延迟。
- 副本利用率：如果副本分片未被充分利用，说明查询路由策略或节点负载均衡需要优化。