# 从一次深夜搜索超时到多租户商品搜索平台：Spring Data Elasticsearch 生产排障与收口

```text
旧方案：Repository 直接查 ES，超时只重试 → 冲突：重试放大慢查询，节点被打满 → 后果：搜索雪崩，租户互相影响
```

我是老李，今晚又被值班电话叫起来。商品搜索接口 P99 从 180ms 涨到 4.8s，网关超时率 17%，三个租户同时投诉“搜不出来”。

平台已经上了 ES 7.17、Spring Boot 2.7、Spring Data Elasticsearch 4.4，代码里全是 Repository，查得动就返回，查不动就重试。

这次不是功能缺，是整条链路没人能说清到底卡在哪一层。

为什么每次都是先重试，而不是先定位？

是继续在应用层加缓存、加超时，还是把诊断链固定下来，从 HTTP 一路追到 Lucene 和磁盘？

如果选错，会不会把慢查询重试成集群雪崩，最后连索引重建和降级入口都来不及上？

# 01、故事

```text
02:17 → 生产集群 → 商品搜索超时 → 冲突：三租户投诉，值班只有我一人
```

凌晨两点十七分，生产集群 eu-es-3 的搜索线程池开始堆积。任务是恢复“多租户商品智能搜索平台”的搜索接口。

我打开监控，看到 Spring 侧大量 RestClient 超时，ES 侧 search 队列打满，协调节点 CPU 飙到 92%。

没有现成排障手册，群里只回了一句“先重启试试”。我不敢重启，因为不知道慢查询从哪来。

> 夜深搜索忽然慢
> 三户投诉到值班
> 不知卡在哪一层
> 重启只会更慌乱

# 02、问题

```text
需求变化：单租户商品库 → 多租户实时搜索 → 冲突：wildcard、深分页、大聚合混跑 → 后果：协调节点内存与 CPU 被打满
```

业务从“内部商品库”变成“多租户 SaaS 搜索”，每个租户都自定义筛选、模糊搜索和聚合。

旧 Repository 直接拼 wildcard，分页允许跳到第 500 页，聚合按租户全量桶。

失效原因是查询成本不可控：一个 wildcard 查询要把倒排索引扫一遍，深分页要把前 N 条都排序丢弃。

可验证验收：同一批请求，ES 查询耗时从 4.8s 降到 300ms 以内，且无 Thread Pool Rejected。

> 模糊查询本不轻
> 深页聚合更致命
> 重试一开雪崩起
> 先找证据再决定

# 03、原理

```text
核心机制：查询先到协调节点，再广播到数据节点，最后在 Lucene 段上执行并合并
```

一个搜索请求进入 ES 后，协调节点负责分发和合并，数据节点负责分片级查询，Lucene 负责倒排索引与正排读取。

wildcard 查询无法用倒排索引精确跳转，只能扫描匹配项；深分页需要协调节点堆内存保存全局排序窗口。

反直觉判断：ES 返回快不代表查询便宜，from+size 越大，协调节点内存和 GC 压力越大，甚至比返回慢更危险。

> 协调节点先接单
> 分片并发各自算
> 合并排序最耗神
> 深页一拉内存满

# 04、架构

```text
输入：HTTP 搜索请求 → 本模块：Spring Search API + ES 查询链 → 输出：商品结果、聚合、高亮；边界：不直接操作 Lucene 与磁盘
```

应用层负责租户隔离、查询模板、权限过滤和降级；ES 层负责索引、检索、聚合和排序。

边界是：Spring 不拼原始 JSON 查询，ES 不感知租户业务规则，只接收带过滤条件的结构化查询。

收益是查询可审计、可限流、可降级；代价是应用层要维护查询构建规范，不能随意用 Repository 派生查询。

适用条件：多租户、复杂筛选、聚合和高亮并存的搜索场景；简单 CRUD 不必引入这套约束。

> 应用管租户规则
> 引擎管索引检索
> 边界不清最致命
> 慢查一来全推责

# 05、第一版实战

```text
环境：JDK 11 + Spring Boot 2.7.18 + Spring Data Elasticsearch 4.4.18 + ES 7.17.20 → 配置 → 代码 → 启动 → 验证 → V1
```

先搭最小复现环境，使用 Testcontainers 启动 ES 7.17.20。

```yaml
spring:
  elasticsearch:
    uris: localhost:9200
    connection-timeout: 1s
    socket-timeout: 2s
```

```java
@Document(indexName = "product_v1")
public class ProductDoc {
    @Id
    private String id;
    @Field(type = FieldType.Text)
    private String name;
    @Field(type = FieldType.Keyword)
    private String tenantId;
    @Field(type = FieldType.Double)
    private BigDecimal price;
    @Field(type = FieldType.Keyword)
    private String category;
}
```

```java
public interface ProductRepository extends ElasticsearchRepository<ProductDoc, String> {
    List<ProductDoc> findByNameContainingAndTenantId(String name, String tenantId);
}
```

启动后写入 50 万条商品数据，执行验证请求。

```bash
curl -s 'http://localhost:9200/product_v1/_search?pretty' -H 'Content-Type: application/json' -d '{
  "query": {"bool":{"must":[{"wildcard":{"name":"*手机*"}},{"term":{"tenantId":"t-1001"}}]}},
  "from":0,"size":20
}'
```

示例输出：

```text
{
  "took" : 4820,
  "timed_out" : false,
  "hits" : {"total" : 18320, "max_score" : 1.0, "hits" : [ ... ]}
}
```

V1 能返回结果，但 took 4.8s，成功标准未达到：P99 需小于 300ms。

> 第一版能查通
> 慢查却藏其中
> 只看功能不算完
> 指标不过皆成空

# 06、排查

```text
诊断树：HTTP 超时 → Spring 线程等待 → ES Client Pool 耗尽 → 网络重传 → 协调节点排队 → 分片慢 → Lucene 扫描 → 磁盘 IO 高
```

第一个问题：搜索接口偶发 504。怀疑网关超时，检查 Spring 日志，发现大量 socket timeout。

```bash
curl -s 'http://localhost:9200/_cat/thread_pool/search?v&h=node_name,name,active,queue,rejected'
```

示例输出：

```text
node-1 search 12 186 37
node-2 search 9 143 21
node-3 search 15 201 44
```

证据是 rejected 持续增长，根因是 wildcard 慢查询占满搜索线程池。

第二个问题：ES 节点 CPU 高但磁盘 IO 也高。怀疑段合并，检查段数量。

```bash
curl -s 'http://localhost:9200/_cat/segments/product_v1?v&h=index,shard,segment,size.memory,committed'
```

示例输出：

```text
product_v1 0 _a 1.2gb true
product_v1 0 _b 1.1gb true
product_v1 0 _c 0.9gb true
```

根因是 3 个分片各含大量小段，wildcard 查询跨段扫描成本翻倍。

**错误尝试：** 第一次直接调大 socket-timeout 到 10s，结果请求更慢，线程池 rejected 反而增加。

> 先看线程池拒绝
> 再看段数与分片
> 莫把超时当解药
> 证据链断必误判

# 07、优化

```text
V1：wildcard + 深分页 + 大聚合 → 证据：rejected 37、took 4.8s、段数 3×N → V2：nGram 子字段 + search_after + 限制聚合桶
```

把 wildcard 改成 nGram 子字段，用 match 查询替代扫描。

```java
@Field(type = FieldType.Text, analyzer = "ik_max_word", searchAnalyzer = "ik_smart")
private String name;

@Field(type = FieldType.Text, analyzer = "ngram_analyzer")
private String nameNgram;
```

```json
{
  "settings": {
    "analysis": {
      "analyzer": {
        "ngram_analyzer": {
          "tokenizer": "ngram_tokenizer",
          "filter": ["lowercase"]
        }
      },
      "tokenizer": {
        "ngram_tokenizer": {
          "type": "ngram",
          "min_gram": 2,
          "max_gram": 3
        }
      }
    }
  }
}
```

深分页改为 search_after，禁止 from+size 超过 1000。

```java
SearchHits<ProductDoc> searchAfter(String tenantId, Object[] sortValues, int size);
```

聚合限制桶数量，租户维度最多 50 个分类桶。

```java
NativeQuery query = NativeQuery.builder()
    .withAggregation("by_category", Aggregation.of(a -> a.terms(t -> t.field("category").size(50))))
    .build();
```

> wildcard 换成 nGram
> 深分页改 search_after
> 聚合桶数设上限
> 慢查才肯低下头

# 08、演进

```text
V2：nGram + search_after + 聚合限桶 → 能力：可审计查询、可限流、可降级 → 遗留：节点不可用与同步失败未覆盖
```

用 V1 同一组请求验证：took 从 4.8s 降到 210ms，rejected 归零，P99 稳定在 260ms。

收益是查询成本可控，协调节点内存不再因深分页暴涨；代价是索引体积增加约 35%，写入延迟略升。

适用条件：模糊搜索、分页浏览、租户聚合并存的场景；纯精确匹配不必引入 nGram。

遗留问题：节点宕机时客户端仍直接报错，MySQL 到 ES 的同步失败没有重放与对账机制。

> 慢查已按下
> 深页不再拉
> 节点若倒下
> 同步还会差

# 09、洞见

```text
从现象到判断：不是 ES 慢，是查询成本没有被工程化约束
```

## 反直觉判断：先限制查询形状，再谈性能优化
```text
查询形状 → 成本上限 → 线程池与内存安全
```

很多人一上来调 JVM、加机器，但真正的风险是任意 wildcard、任意深分页、任意聚合桶数。

先把查询形状关进笼子，性能优化才有意义。

## 反直觉判断：ES 返回快不代表查询便宜
```text
返回快 → 可能只取前 N 条 → 但排序窗口仍占内存
```

一个 from=10000 的查询可能返回 20 条只要 50ms，但协调节点已经为 10020 条排序分配堆内存。

判断查询成本要看线程池、GC 和内存，不能只看 took。

## 诊断链要固定，不能每次从中间猜
```text
HTTP → Spring Thread → ES Client Pool → Network → Coordinating Node → Shard → Lucene → Disk
```

固定诊断链后，每次超时都从最外层开始排除，避免一上来就怀疑 ES 或 Lucene。

## 生产指标要能回答“现在能不能扛住”
```text
_cluster/health + _cat/nodes + _cat/shards + Slow Log + Profile + Explain + Heap/GC + Rejected + Watermark + Segment + Shard 数 + Query Cache
```

这些指标不是背下来，而是形成一条证据链：健康、资源、队列、慢查询、执行计划、段与磁盘。

> 慢查不是玄学
> 成本皆有形状
> 指标连成证据
> 排障才有方向

# 10、系统落地

```text
入口：Spring Search API → 服务：查询构建、租户过滤、降级 → 本模块：ES 索引与检索 → 存储：MySQL + ES → 未实现：自动故障转移与同步对账
```

原来只有 MySQL 和简单 Repository 查询；本篇增加 nGram 子字段、search_after、聚合限桶、诊断链和指标采集。

现在能做：多租户商品搜索、模糊匹配、分页、聚合、高亮，且慢查询可控、故障可定位。

下一篇缺：节点不可用时的自动降级、MySQL 到 ES 的同步失败重放、索引重建的自动化流程。

官方文档以 Elastic 官方文档主页和 Spring Data Elasticsearch 文档首页为准，版本细节需按当前官方文档核验。

> 入口到服务
> 服务到索引
> 索引到磁盘
> 缺一环不完整

# 11、小结

```text
三问三答：为什么先定位？因为重试会放大慢查询；怎么选？固定诊断链并限制查询形状；选错后果？雪崩与租户互扰
```

第一问：为什么每次都是先重试而不是先定位？因为缺少固定诊断链，团队只会用重试掩盖超时。

第二问：是加缓存加超时，还是固定诊断链追到底？答案是先固定诊断链，再限制查询形状，最后才考虑缓存。

第三问：选错会怎样？会把慢查询重试成集群雪崩，租户互相影响，连降级和重建都来不及上。

当前状态：V2 已稳定，诊断链已固定，指标采集已接入，但节点故障和同步对账仍是遗留。

> 三问皆已答
> 慢查不再怕
> 节点与同步
> 留待下一篇

# 12、作业

```text
理解 → 实战 → 排障 → 架构判断
```

## 理解题：为什么 wildcard 查询在 ES 中容易变成慢查询？

因为 wildcard 无法利用倒排索引精确跳转，需要扫描匹配项，查询成本随索引规模线性上升，容易占满搜索线程池。

## 实战题：用 Testcontainers 启动 ES 7.17，写入 10 万条商品，复现 wildcard 慢查询并改用 nGram 子字段验证耗时下降。

先按 V1 写入数据并执行 wildcard 查询，记录 took；再创建带 nGram 子字段的索引，reindex 后执行 match 查询，对比 took 和线程池 rejected。

## 排障题：搜索接口超时，_cat/thread_pool 显示 search rejected 持续增长，如何定位根因？

先看 _cat/thread_pool 确认拒绝发生在搜索线程池；

再开 Slow Log 抓慢查询；

用 Profile API 看查询在哪个分片、哪个 Lucene 操作耗时最高；

最后用 _cat/shards 和 _cat/segments 确认分片与段分布。

## 架构判断题：多租户搜索平台是否应该允许每个租户自定义任意 wildcard 和任意深分页？

不应该。多租户平台必须限制查询形状，例如用 nGram 替代 wildcard、用 search_after 替代深分页、限制聚合桶数，否则单个租户的慢查询会拖垮整个集群。

> 理解要透
> 实战要真
> 排障要证
> 架构要稳

# 13、升华

```text
工程结论：真正掌握 Spring Data Elasticsearch，不是会写 Repository，而是能从业务搜索问题追到 Analyzer、Mapping、Query、Ranking、Shard、Lucene 和生产指标
```

这次收口证明：搜索系统的稳定性不取决于 ES 本身，而取决于工程化约束和诊断链是否固定。

从 HTTP 到 Spring Thread，再到 ES Client Pool、Network、Coordinating Node、Shard、Lucene、Disk，每一层都有对应指标和工具。

多租户商品智能搜索平台最终形成 MySQL → CDC/MQ → ES → Spring Search API → Keyword/Filter/Aggregation/Highlight/Geo/V

ector/Hybrid 的完整链路。

同时具备 Docker、Testcontainers、Alias/Reindex、指标监控、故障降级和索引重建能力。

下一篇将补齐节点不可用时的自动降级、同步失败重放与索引重建自动化，让平台从“能查”走向“能扛”。

> 从业务到索引
> 从查询到磁盘
> 指标连成链
> 平台才收口

**系列项目：** 多租户商品智能搜索平台

**已完成：** MySQL 存储、Spring Search API、ES 索引与检索、nGram 模糊匹配、search_after 分页、聚合限桶、诊断链与指标采集

**本篇：** 生产排障收口、慢查询治理、查询形状约束、诊断工具链落地

**下一篇：** 节点故障自动降级、MySQL→ES 同步失败重放、索引重建自动化

我是老李，今晚又被值班电话叫起来。商品搜索接口 P99 从 180ms 涨到 4.8s，网关超时率 17%，三个租户同时投诉“搜不出来”。

《Spring ES实战》第16招 上线后怎么排障

以一次商品搜索超时为线，从 HTTP 追到 Lucene 与磁盘，完成诊断链、工具链与多租户搜索平台收口。

架构师

数据库

后端

架构设计

搜索接口P99从180ms恶化至4.8s，根因是wildcard与深分页导致ES线程池耗尽。通过nGram子字段替代模糊扫描、search_after限制分页深度、聚合桶数封顶及固定诊断链，查询耗时降至210ms，拒绝数归零。多租户场景需先约束查询形状，再谈性能优化，避免重试放大慢查询引发集群雪崩。

Elasticsearch 

代码解释

MySQL

SaaS

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

《Spring ES实战》第16招 上线后怎么排障-腾讯云开发者社区-腾讯云

《Spring ES实战》第16招上线后怎么排障

《Spring ES实战》第16招上线后怎么排障

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring ES实战》第16招 上线后怎么排障

《Spring ES实战》第16招 上线后怎么排障

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

《Spring ES实战》第16招上线后怎么排障

《Spring ES实战》第16招上线后怎么排障