📚 课程目录第2章搜索服务架构基础

2. 搜索服务架构基础：典型搜索服务调用链与连接池位置

在压测连接池超时参数对尾延迟的影响之前，必须清晰理解搜索服务的整体调用拓扑。搜索服务通常采用分层聚合架构，请求从用户端发起，经过网关、聚合层、索引层三个核心阶段，每一层之间通过连接池管理下游连接。连接池的配置直接决定了请求在层间等待资源的时长，进而影响尾延迟。

下图展示了搜索服务一次完整查询请求的调用链路，以及连接池在每一层之间的位置：

层级	核心职责	连接池位置	连接池典型参数
网关层	协议转换、限流、鉴权、路由分发	网关 → 聚合层	maxTotal: 200, maxWaitMillis: 50ms
聚合层	请求拆分、并行查询、结果合并	聚合层 → 索引层	maxTotal: 500, maxWaitMillis: 100ms
索引层	倒排检索、向量检索、打分排序	（内部无连接池，直接处理请求）	—

  关键理解：连接池只存在于调用方一侧。网关层持有连接池管理到聚合层的连接；聚合层持有连接池管理到索引层的连接。索引层作为服务端，不主动维护连接池，而是由操作系统 TCP 栈管理 accept 队列。

连接池位于层间 RPC 调用的客户端侧。以聚合层为例，其内部连接池的工作流程如下：

请求到达聚合层：聚合层收到网关转发的查询请求。
拆分请求：将查询拆分为多个索引分片请求（例如 6 个分片）。
从连接池获取连接：为每个分片请求从连接池中获取一个可用连接。
等待策略：
- 若连接池有空闲连接 → 立即获取，发送请求。
- 若连接池无空闲且未达上限 → 创建新连接。
- 若连接池已满 → 根据 maxWaitMillis 等待，超时则抛出异常。
释放连接：请求完成后将连接归还连接池。

连接池超时参数（尤其是 maxWaitMillis）直接影响请求在等待连接阶段的耗时。当系统处于高负载或下游抖动时，连接池耗尽概率上升，等待超时成为尾延迟的主要贡献者：

场景	连接池状态	请求等待时间	对尾延迟影响
低负载	空闲连接充足	≈ 0ms	无影响
中等负载	偶发等待	1~10ms	轻微增加 P99
高负载	频繁等待	50~200ms	显著抬高 P99.9
连接池耗尽 + 超时	全部连接被占用	maxWaitMillis 值	直接成为尾延迟上限

压测关注点：本课程后续章节将重点验证 maxWaitMillis 从 50ms 调整到 500ms 时，P99.9 延迟的变化曲线。连接池等待超时是搜索服务尾延迟的可控变量之一。

以下表格将连接池核心参数与调用链中的实际行为对应起来，便于后续压测时理解参数调整的影响范围：

参数	含义	在调用链中的表现	尾延迟敏感度
`maxTotal`	连接池最大连接数	决定聚合层能同时发起的索引请求数上限	中
`maxIdle`	最大空闲连接数	影响低负载时的连接复用效率	低
`minIdle`	最小空闲连接数	预热后减少连接创建延迟	低
`maxWaitMillis`	获取连接的最大等待时间	连接池耗尽时，请求在此参数内阻塞等待	高
`timeBetweenEvictionRunsMillis`	空闲连接驱逐检查间隔	影响连接健康度，间接影响获取连接成功率	中

常见误区：很多开发者只关注 maxTotal 而忽略 maxWaitMillis。实际上，在突发流量场景下，maxWaitMillis 是尾延迟的直接决定因素。即使连接数足够大，如果等待时间设置过长，P99.9 仍然会被拉高。