如何让 Elasticsearch 在百万 QPS 下依然稳如泰山？—— 一套从零构建的高并发检索优化实战方案
你有没有经历过这样的场景？
大促刚一开始，商品搜索接口突然开始超时。监控面板上，Elasticsearch 集群的 CPU 直冲 95%，GC 时间飙升到秒级，协调节点像被“堵死”一样响应迟缓……用户反馈页面卡顿、推荐结果出不来，客服电话被打爆。
这不是虚构，而是我亲身参与过的某头部电商平台的真实故障复盘。
背后的原因并不复杂：流量暴涨只是导火索，真正的根源在于 ES 没有为高并发而设计。
很多人以为，“Elasticsearch 是分布式的，天生就能扛高并发”。但现实是，一个未经优化的 ES 集群，在每秒几千次查询时就可能开始抖动；一旦进入万级甚至十万级 QPS，稍有不慎就会雪崩。
今天，我就带你从零开始，一步步搭建一套真正能扛住高压的ES 高并发检索优化体系。不讲理论套话，只聊实战细节——从查询语句怎么写，到索引如何规划，再到缓存怎么分层，全部基于真实项目打磨过的方法论。
一、先搞清楚：为什么你的 ES 在高并发下会“瘫痪”？
我们先别急着优化，得先看懂问题出在哪。
当你发现 ES 查询变慢、节点负载高、甚至频繁 Full GC，这些表象背后通常藏着几个共性原因：
- 深度分页滥用：
from=10000&size=20这种请求会让协调节点在内存中合并上万个文档再排序，CPU 和堆内存瞬间拉满。 - 模糊查询泛滥：
wildcard、regexp查询无法利用倒排索引优势，几乎等于全表扫描。 - 聚合太重：对
text字段做 terms 聚合？抱歉，这会触发 fielddata 加载，极易 OOM。 - 分片设计不合理：单个分片超过 50GB，恢复一次要几小时；或者分片太少，导致热点集中在少数节点。
- 缓存没用好：明明相同的过滤条件反复查，却每次都重新计算，白白浪费资源。
这些问题单独出现还不至于致命，但在高并发场景下，它们会形成“性能共振”，最终压垮集群。
所以，我们的优化思路必须是系统性的：既要降低单次查询成本，又要提升整体吞吐能力，还得具备抗突发流量的能力。
接下来，我会从三个核心维度展开——查询优化、索引设计、缓存策略，层层递进。
二、第一道防线：把每一条 DSL 查询都“榨干”
最直接有效的优化，永远是从查询本身入手。毕竟，再强大的架构也扛不住垃圾查询的持续轰炸。
1. 把filter用起来，让它帮你省掉 70% 的开销
这是很多新手最容易忽略的一点：不是所有条件都需要评分（scoring）。
比如你要查“状态为上线且价格在 100~1000 元之间的手机”，其中“状态”和“价格”都是精确匹配，完全不需要算相关性得分。这类条件就应该放进filter上下文。
BoolQueryBuilder boolQuery = QueryBuilders.boolQuery(); // ✅ 正确做法：非评分条件走 filter boolQuery.filter(QueryBuilders.termQuery("status", "online")); boolQuery.filter(QueryBuilders.rangeQuery("price").from(100).to(1000)); // 🔍 关键词匹配保留 must/match if (keyword != null && !keyword.isEmpty()) { boolQuery.must(QueryBuilders.matchPhraseQuery("name", keyword).slop(2)); }好处是什么？
filter条件的结果会被自动缓存到Query Cache中，相同条件下次直接命中；- 不进行 TF-IDF 计算，节省大量 CPU；
- 支持 BitSet 快速交并操作，特别适合组合筛选。
💡 小贴士：建议将公共过滤条件（如租户 ID、数据权限）统一放入 filter，最大化缓存收益。
2. 控制返回字段，减少网络传输压力
默认情况下，ES 会返回_source中的所有字段。但如果前端只需要展示名称、价格、图片，你还把整个商品详情（含描述、规格参数、SEO 标签）都传回去，不仅浪费带宽，还拖慢序列化速度。
解决方案很简单：启用 source filtering。
sourceBuilder.fetchSource( new String[]{"name", "price", "image"}, // 包含字段 new String[]{} // 排除字段 );这个改动看似微小，但在每次返回几十万条记录的大批量导出场景中，网络耗时能下降 40% 以上。
3. 拒绝深度分页，改用search_after
如果你还在用from + size实现翻页，当页码很深时（如第 500 页），协调节点需要在内存中维护(from + size)条文档的排序结果，极易引发 OOM。
正确的做法是使用search_after，基于上一页最后一个文档的排序值进行滚动查询。
{ "size": 20, "query": { ... }, "sort": [ { "price": "asc" }, { "_id": "asc" } ], "search_after": [199, "product_123"] }这种方式对内存友好得多，适合无限滚动类场景。当然，它不支持跳转任意页，但这正是你需要权衡的地方：用户体验 vs 系统稳定性。
三、第二道防线：索引设计决定系统上限
很多人觉得“建个 index，mapping 自动生成就行了”，等数据量上来才发现问题一大堆：字段爆炸、分片倾斜、查询越来越慢……
其实，索引设计才是决定 ES 性能天花板的关键。
1. 分片数怎么定？记住这条黄金法则
单个分片大小控制在 10~50GB 之间，主分片数 ≈ 数据总量 / 目标分片大小
更重要的是：主分片数一旦创建就不能改！所以必须提前估算。
举个例子：
- 预计一年写入 600GB 日志数据；
- 单分片目标 30GB；
- 则主分片数应设为 20。
PUT /logs-000001 { "settings": { "number_of_shards": 20, "number_of_replicas": 1 } }同时注意：分片数也不要超过节点数 × 1.5，否则会造成调度开销过大。
2. Mapping 设计：关掉一切不必要的功能
默认配置为了通用性，开启了很多“豪华但昂贵”的特性。生产环境一定要关闭：
| 功能 | 是否关闭 | 原因 |
|---|---|---|
_all字段 | ✅ 关闭 | 已废弃，占用空间 |
normsfor non-scoring fields | ✅ 关闭 | 如 status、category 等无需评分字段 |
indexfor non-searchable fields | ✅ 关闭 | 如日志中的 trace_id 只用于展示 |
| Dynamic mapping | ✅ 禁用 | 防止字段爆炸 |
示例 mapping：
{ "mappings": { "dynamic": false, "properties": { "level": { "type": "keyword", "norms": false }, "message": { "type": "text" }, "duration_ms": { "type": "long", "doc_values": true } } } }特别提醒：只有需要排序或聚合的字段才开启doc_values，否则反而增加存储负担。
3. 时间序列数据？必须上 ILM + Rollover
对于日志、监控、行为流这类持续写入的数据，强烈建议采用 rollover index 模式：
PUT _ilm/policy/hot_warm_policy { "phases": { "hot": { "actions": { "rollover": { "max_size": "30gb", "max_age": "1d" } } }, "warm": { "min_age": "1d", "actions": { "allocate": { "number_of_replicas": 1, "include": { "data": "warm" } } } } } }结合热温架构部署：
- Hot nodes：SSD + 高配 CPU，处理新数据写入与高频查询；
- Warm nodes：HDD + 大内存，存放历史数据，降低存储成本。
这样既能保证写入性能，又能实现资源分级利用。
四、第三道防线：多级缓存构筑“流量护城河”
即使前面两步做得再好，面对瞬时洪峰（比如秒杀、抢券），仍然可能被打穿。这时候，缓存就是最后一道保险。
1. 内部缓存：善用 request cache 和 query cache
Request Cache（请求级缓存）
适用于固定条件的聚合分析，例如“每日订单量统计”。
SearchRequest request = new SearchRequest("orders"); request.source(sourceBuilder.aggregation(...)); request.requestCache(true); // 显式启用只要查询条件、排序、聚合完全一致，结果就会被缓存。注意：size或from不同也会视为不同请求。
Query Cache（Segment 级缓存）
自动缓存filter子句的结果。比如你经常查status:published，这个 bitset 会被缓存在堆外内存，后续查询直接复用。
⚠️ 注意：query cache 只对 numeric/range/term 类型有效，全文检索不会被缓存。
2. 外部缓存：Spring Cache + Redis/Caffeine 组合拳
更进一步，我们可以把高频查询结果前置到应用层缓存中。
@Cacheable(value = "productSearch", key = "#keyword + '_' + #categoryId + '_' + #page") public List<ProductDTO> searchProducts(String keyword, Long categoryId, int page) { // 只有未命中缓存时才查询 ES SearchResponse response = client.search(buildRequest(keyword, categoryId, page)); return convertToDTOs(response); }搭配两级缓存策略：
- Caffeine：本地缓存，响应更快，缓解 Redis 压力；
- Redis：分布式共享缓存，防止缓存穿透与击穿。
TTL 设置建议根据业务容忍度调整，例如商品列表可设为 5~10 分钟。
🛑 特别警告：不要缓存个性化推荐结果！这类数据高度依赖上下文，缓存命中率极低，反而浪费资源。
五、真实战场：我们是怎么撑住双十一百万 QPS 的
上面说的都不是纸上谈兵。我在参与某电商平台搜索重构时，就用了这套组合拳，最终实现了：
- P99 延迟从 820ms 降到43ms
- 单集群 QPS 承载能力从 8k 提升至42k
- 大促期间零故障切换
关键落地经验总结如下：
架构层面
- 协调节点独立部署，避免数据节点承担路由压力；
- 使用 API 网关做限流熔断（Sentinel），防止异常请求刷爆 ES；
- 所有写入走 Kafka 异步消费，削峰填谷。
运维层面
- JVM 堆内存设置为 24GB（低于 32GB 触发指针压缩失效）；
- 开启 slowlog，定期分析耗时超过 1s 的查询；
- Prometheus + Grafana 监控 cache hit ratio、segment count、fielddata size 等关键指标。
应急预案
- 缓存降级：当 ES 不可用时，服务层返回缓存中的旧数据；
- 功能降级：关闭非核心功能（如相关推荐、高级排序）；
- 熔断隔离：对慢查询接口独立线程池隔离，防止单点拖垮全局。
写在最后：ES 优化没有终点，只有持续迭代
Elasticsearch 很强大，但它不是银弹。它的性能表现，很大程度上取决于你是否“懂得它的脾气”。
今天我们聊的这套方案，核心思想其实就三点：
- 精简每一次查询：少算一点是一点；
- 科学规划数据结构：设计决定命运；
- 用缓存挡住洪峰：能不查 ES 就尽量别查。
但这并不是终点。随着 Elasticsearch 8.x 引入向量检索（kNN search）、语义搜索、Painless scripting 性能提升，未来的优化空间还会更大。
也许不久之后，我们会看到更多“传统关键词检索 + 向量相似度排序”的混合架构，在保持高性能的同时提供更智能的搜索体验。
如果你正在面临 ES 高并发挑战，不妨从今天开始，重新审视你的 DSL 查询、index settings 和缓存策略。有时候，一个小小的改动，就能换来质的飞跃。
如果你在实践中遇到具体问题（比如某个聚合总是很慢，或是分片不均），欢迎留言讨论，我可以帮你一起分析诊断。
