避免 Elasticsearch 查询导致集群负载过高崩溃的核心在于优化查询语句、合理规划分片及监控资源使用。首先，慎用通配符查询，尤其是前缀通配符，避免全表扫描导致 CPU 飙高；其次，合理设置分片数量与大小，单分片建议控制在 20GB-50GB 之间，避免分片不均导致个别节点负载过高；此外，定期执行 force merge 减少 segment 数量，提升检索效率；最后，开启慢日志监控，及时发现并优化高消耗查询请求，必要时进行集群扩容或升配，确保系统稳定性。

一行代码，让 Elasticsearch 集群瞬间雪崩——5000W 数据压测下的性能避坑全攻略

作为一名长期与 Elasticsearch 打交道的引擎研发，我见过太多集群因为一个看似无害的 wildcard 模糊查询而瞬间崩溃。许多开发者继承了 SQLLIKE %% 的思维习惯，直接把它搬到 ES 中——在小数据量时没什么大碍，但当文档量上亿时，它会变成拖垮集群的性能黑洞：轻则：错用字段类型，查不准结果，浪费存储 重则：暴力扫描，CPU 瞬间打满，集群直接假死 为什么会这样？又该怎么避免？接下来，我们将深入解析这些问题原因和其解决方案。我们特意在 5000 万级数据量下做了高压测试，用真实数据复刻事故现场，让你一眼看懂问题的根源与规避方案。对 ES 用户及技术开发爱好者而言，这是一份不可错过的技术文章。不同查询场景的最佳选型建议 针对不同场景，我们给出以下实战建议：

Elasticsearch 干货 (九):Elasticsearch 崩溃风险

本文介绍了使用 Elasticsearch 时应避免的操作，以防止集群性能下降或崩溃。包括慎用通配符查询以减少数据集压力，避免对分词字段进行聚合查询以降低内存消耗，控制聚合基数以减少系统开销，以及理解 Mapping 动态修改带来的影响，并建议设置`dynamic=false`。遵循这些最佳实践，可以有效提升 Elasticsearch 的稳定性和效率。我们在使用 Elasticsearch 时应该选择性的避免一些可能导致集群变慢甚至崩溃的操作，这是非常必要的。通配符 我们在查询时，或多或少可能会用到通配符 (比如:*) 来进行查询操作。但是一个通配符下对应的往往是非常大的数据集，这种情况下，很容易导致集群变慢。所以我们在使用通配符时一定要注意，通配符下的数据集是否过大。

如何解决 Elasticsearch 集群负载不均的问题？

说明 本文另有延续:Elasticsearch 集群 CPU 使用率过高的问题 背景 ES 集群在某些情况下会出现 CPU 使用率高的现象，具体有两种表现：1. 个别节点 CPU 使用率远高于其他节点; 2. 集群中所有节点 CPU 使用率都很高。本篇文章我们着重讲解第一种情况。问题现象 集群在某些情况下会个别节点 CPU 使用率远高于其他节点的现象。从监控中可以明显看到某些节点 CPU 使用率居高不下。原因 出现这种情况，由于表面上看集群读写都不高，导致很难快速从监控上找到根因。所以需要细心观察，从细节中找答案，下面我们介绍几种可能出现的场景以及排查思路。原因一:Shard 设置不合理 1. 登录 Kibana 控制台，在开发工具中执行以下命令，查看索引的 shard 信息，确认索引的 shard 在负载高的节点上呈现的数量较多，说明 shard 分配不均;

elasticsearch 高负载问题场景分析

问题原因：磁盘文件系统只读是机器本身 Linux 的文件系统触发了只读。解决办法：在 CVM 中使用 fsck 命令修复文件系统，解除只读状态。触发背景：集群长时间大量写入的情况下会小概率发生。表现形式：集群健康状态非绿。写入速度突然下降。注：磁盘文件系统只读非 es 集群只读和索引只读。切勿混淆。2. 节点频繁离线 集群内节点负载过高，频繁脱离集群，引起健康状态变化，节点分片未分配，影响集群业务。表现形式：日志中有明显的 node-left 日志。监控中部分节点资源使用率过高。例如:CPU 使用率过高，节点 load 长时间打满。JVM 堆内存使用率过高，集群熔断。解决办法：① CPU 使用过高，load 持续打满情况 需要结合机架监控，集群监控，分析集群当前业务的实际情况与与集群状态，索引分片配置等。可以使用 GET _tasksAPI 来确认一下集群当前主要的任务。进而明确导致 CPU 使用率过高的原因。然后引导用户进行节点规格升级等操作。

Elasticsearch 集群 CPU 使用率过高的问题

ES 集群在某些情况下会出现 CPU 使用率高的现象，具体有两种表现：1. 个别节点 CPU 使用率远高于其他节点; 2. 集群中所有节点 CPU 使用率都很高。本篇文章我们着重讲解第二种情况。问题现象 集群所有节点 CPU 都很高，但读写都不是很高。图中可以看到，kibana 端 Stack Monitoring 的监控，CPU 使用率每个节点都很高。原因 出现这种情况，由于表面上看集群读写都不高，导致很难快速从监控上找到根因。所以需要细心观察，从细节中找答案，下面我们介绍几种可能出现的场景以及排查思路。原因一：比较大的查询请求导致 CPU 飙高 这种情况比较常见，细心一点的话可以从监控上找到线索：从监控上可以发现，查询请求量的波动与集群最大 CPU 使用率是基本吻合的。发现了问题所在，进一步确认则需要开启集群的慢日志收集，可以参考官方文档：集群日志说明。从慢日志中，我们可以得到更多信息。比如引起慢查询的索引、查询参数以及内容。解决方案 针对这种情况，我们一般建议：1. 尽量避免大段文本搜索，优化查询; 2. 通过慢日志确认查询慢的索引，对于一些数据量不大的索引，设置少量分片多副本，比如 1 分片多副本，以此来提高查询性能; 3. 考虑集群升配扩容。

集群负载不均问题的分析方法及解决方案

导致阿里云 Elasticsearch(简称 ES) 的负载不均问题的原因很多，目前主要包括 shard 设置不合理、segment 大小不均、冷热数据需求、负载均衡及多可用区架构部署的长连接不释放等。本文介绍 ES 集群负载不均问题的分析方法及解决方案。问题现象 节点间磁盘使用率差距不大，监控中节点 CPU 使用率或 load_1m 呈现明显的负载不均衡现象。节点间磁盘使用率差距很大，监控中节点 CPU 使用率或 load_1m 呈现明显的负载不均衡现象。问题原因 Shard 设置不合理。重要 大多数负载不均问题是由于 shard 设置不合理导致，建议优先排查。Segment 大小不均。存在典型的冷热数据需求场景。重要 冷热数据场景 (例如查询中添加了 routing、查询频率较高的热点数据) 必然导致数据出现负载不均。采用负载均衡及多可用区架构部署时，由于长连接不释放可能会导致流量不均 (很少出现),详情请参见长连接不均匀。重要 其他情况导致的负载不均问题，请联系阿里云技术支持工程师排查。Shard 设置不合理 场景 A 公司有一个阿里云 ES 实例，该实例配置为:3 个主节点 16 核 32GB、9 个数据节点 32 核 64GB，主要数据保存在 test 索引上。当在业务高峰期的时候 (16:21~18:00 左右),查询 QPS 为 2000 左右 (查询中没有冷热数据分离)、写入 QPS 为 1000、2 个节点的 CPU 达到 100，负载过高影响 ES 服务。分析 优先检查查询期间的网络及 ECS 情况。如果 ECS 环境正常，再查看网络流量监控。根据监控结果发现异常期间 (16:21) 网络请求上升，查询 QPS 上升，对应的 CPU 节点负载大幅增高。结合查询策略，初步判断负载高的节点主要承担了查询请求。使用 GET _cat/shards?v，查看索引的 shard 信息。从结果可以看到 test 索引的 shard 在负载高的节点上呈现的数量较多，说明 shard 分配不均;然后查看磁盘使用率监控图，显示负载高的节点使用率比其他节点高。由此可以得出，shard 分配不均衡导致存储不均，在业务查询或写入中，存储高的节点承担主要的查询和写入。使用 GET _cat/indices?v，查看索引信息。从结果可以看到索引的主 shard 数量为 5，副 shard 数量为 1。结合集群配置，发现存在节点 shard 分配不均的现象，其次集群中存在被删除的文档。ES 在检索过程中也会检索.del 文件，然后过滤标记有.del 的文档，大大地降低检索效率，耗费规格资源，建议在业务低峰期进行 force merge。查看主日志及 searching 慢日志。从结果可以看到查询请求都是普通的 term 查

FAQ

为什么通配符查询会导致集群崩溃？

因为通配符下对应的往往是非常大的数据集，容易导致集群变慢，甚至暴力扫描导致 CPU 瞬间打满。

如何排查 CPU 使用率过高的问题？

可以通过开启集群的慢日志收集，确认查询慢的索引、查询参数以及内容，或者获取 hot_threads 信息确认什么线程在消耗 CPU。

分片设置不合理会有什么影响？

会导致负载不均，存储高的节点承担主要的查询和写入，极易引起文件句柄耗尽，导致集群故障。

如何优化 Segment 过多导致的性能差？

在业务低峰期进行强制合并操作，减少 segment 数量，具体请参见 force merge。