从零实现es数据库高并发检索优化方案

如何让 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`字段	✅ 关闭	已废弃，占用空间
`norms`for non-scoring fields	✅ 关闭	如 status、category 等无需评分字段
`index`for 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 分钟。