1. 项目概述：为什么集群不是“堆机器”，而是请求的精密调度系统

“elasticsearch-集群处理不同请求”这个标题，乍看像一句技术文档里的常规描述，但真正跑过生产环境的人一眼就能看出——它背后藏着的是每天被千万级QPS反复捶打过的血泪经验。我接触过太多团队，初期把ES当单机用，数据量一上来就卡顿、超时、写入失败；后来加节点，发现查询反而更慢；再后来盲目调高线程池、堆内存，结果OOM频发，集群直接红标。问题从来不在“能不能加机器”，而在于集群如何理解、拆解、分发、响应每一类请求的本质差异。这里的“不同请求”，绝不是简单指“搜索”和“写入”两种动作，而是涵盖：毫秒级关键词检索、聚合分析型OLAP查询、Bulk批量导入、Scroll深分页拉取、Reindex跨索引重建、甚至Watchers告警触发这类后台任务。它们对CPU、内存、磁盘IO、网络带宽、JVM GC压力的消耗模式完全不同。比如一个聚合请求可能瞬间吃光所有data节点的CPU，却几乎不碰磁盘；而Bulk写入则疯狂刷盘、占满IO队列，同时产生大量GC压力。集群若用同一套默认策略去调度，等于让短跑运动员和举重选手共用一套训练计划——表面都在“运动”，实际互相拖累。所以本项目的核心，不是教你怎么搭三节点集群，而是带你一层层剥开ES集群的请求处理流水线：从客户端发起请求开始，到协调节点解析路由，再到数据节点执行具体操作，最后返回结果——每一步，不同请求类型走的是完全不同的内部路径，占用的是隔离的资源池。你看到的“集群健康状态”，其实是几十个独立子系统的协同与博弈结果。这篇文章适合两类人：一类是刚把单机ES迁上集群、发现性能不升反降的运维或开发；另一类是正在设计日志分析平台、商品搜索中台、实时报表系统的架构师——你们需要的不是配置清单，而是理解ES集群如何“思考”请求。接下来的内容，全部基于真实压测场景、线上故障复盘和源码级逻辑梳理，不讲概念，只讲每个参数背后的物理意义和每个步骤的实际代价。

2. 集群请求分类与资源消耗特征深度拆解

要让集群高效处理“不同请求”，第一步必须彻底搞清这些请求到底“不同”在哪里。很多人以为ES请求只有search和index两类，这是最大的认知陷阱。实际上，ES将请求按执行阶段、资源依赖、超时敏感度、可中断性划分为至少7种核心类型，每种在集群内部触发完全不同的处理链路和资源分配策略。

2.1 搜索类请求：毫秒级响应的生命线

搜索类请求（Search API）是ES最典型也最脆弱的一类。它包含普通match查询、bool组合、term精确匹配，也包括复杂的aggs聚合、script脚本计算、highlight高亮。但它们的共性是：对延迟极度敏感，且执行路径高度不可预测。一个简单的match查询可能0.5ms完成，而一个带date_histogram+top_hits的嵌套聚合，可能耗时3s以上。关键点在于，搜索请求的执行分两阶段：Query Phase（协调节点收集各分片结果）和Fetch Phase（根据ID回查原始文档）。前者消耗CPU和网络，后者消耗磁盘IO和内存。我曾在一个电商搜索场景中遇到典型问题：首页搜索词“手机”返回10万条结果，用户滚动到第50页（from=4990），协调节点需在Query Phase合并500个分片的top 5000结果，再排序取前5000，仅此一步就占满协调节点CPU。而Fetch Phase需从磁盘读取5000份文档原文，IO队列直接打满。解决方案不是加协调节点，而是强制改用search_after替代from/size，将排序锚点下推到数据节点，让每个分片只返回自己范围内的结果，Query Phase合并量从5000×500降到5000，性能提升8倍。这说明：搜索类请求的优化，本质是控制协调节点的计算负载，而非单纯提升数据节点性能。

2.2 写入类请求：吞吐量与稳定性的平衡木

写入类请求（Index/Bulk API）的核心矛盾是吞吐量与稳定性之间的零和博弈。Bulk请求看似是一次HTTP调用，实则在服务端被拆解为数百甚至数千个独立的index操作，每个操作都要经历：解析JSON、校验mapping、生成倒排索引、写入translog、刷新segment。其中，translog写入是同步阻塞的（默认），直接绑定磁盘IO；而refresh是异步的，但频繁refresh会生成大量小segment，后续merge压力剧增。我们曾在线上观察到：当bulk size设为10MB（约5万文档）时，单次写入耗时稳定在800ms，但translog写入峰值IO达1.2GB/s，导致同一块SSD上的其他查询请求延迟飙升300%。而将bulk size降至1MB（5千文档），写入耗时升至1.2s，但IO曲线平滑，查询延迟无波动。这揭示了一个硬道理：写入吞吐的瓶颈往往不在ES本身，而在共享存储的IO调度能力。因此，生产环境必须将写入节点与查询节点物理隔离，或至少使用独立磁盘挂载点。另外，Bulk请求中的“action_and_meta_data”行不能省略，否则ES无法做批量解析优化，会退化为单文档循环处理，性能损失可达40%。

2.3 聚合分析类请求：CPU与内存的双重绞杀

Aggregation请求是ES最易被低估的“资源杀手”。一个terms聚合看似简单，但当cardinality（唯一值数量）超过百万时，其内存消耗不是线性增长，而是指数级。ES底层使用Cuckoo Filter和HyperLogLog算法估算基数，但当精度要求高（如设置precision_threshold=40000）时，内存占用会暴涨。我们曾部署一个用户行为分析集群，某天运营同学执行了一个按user_id分组的sum聚合，该字段实际有2300万唯一值。协调节点瞬间申请12GB堆内存用于构建全局聚合桶，触发Full GC，整个集群响应停滞47秒。根本原因在于：聚合的中间结果必须在协调节点内存中完成全局合并，而data节点只返回本地分片的局部结果。因此，聚合类请求的优化铁律是：永远在查询端做数据过滤，绝不把全量数据交给聚合引擎。例如，先用range过滤出最近7天数据，再在此子集上做terms聚合，内存消耗可从12GB降至80MB。另外，避免在高基数字段上使用terms聚合，改用composite聚合分页，或预计算物化视图。

2.4 后台管理类请求：静默却致命的资源窃贼

Reindex、Update By Query、Delete By Query这类API，常被误认为“后台任务不重要”。实则不然。它们以低优先级运行，但会持续占用线程池、内存和CPU。尤其Reindex，本质是启动一个scroll扫描源索引+bulk写入目标索引的完整流程。当源索引有10亿文档时，Reindex任务会持续数小时，期间不断申请heap内存缓存scroll上下文，并占用bulk线程池。我们曾因未限制reindex的slice数量（默认1），导致单个reindex任务独占全部bulk线程，新写入请求全部排队超时。正确做法是显式指定"slices": "auto"或具体数值（如8），让ES自动将任务切分为多个并行子任务，每个子任务独立占用线程池配额，避免单点阻塞。更重要的是，这类请求默认不启用refresh，但结束时会强制refresh，可能引发segment merge风暴。务必在reindex完成后手动执行POST /target_index/_refresh，而非依赖自动行为。

2.5 深分页与Scroll请求：游标机制的双刃剑

from/size分页在10000条后失效，这是ES的硬性限制，源于Lucene的TopDocs机制——它要求每个分片返回足够多的结果供协调节点全局排序。而Scroll请求通过维护服务端游标（scroll_id）规避此限制，但代价是：scroll上下文长期驻留内存，且随存活时间线性增长。一个存活8小时的scroll，若每分钟拉取1万文档，其上下文内存占用可达2GB。更危险的是，scroll不支持实时性，它基于快照执行，期间新写入文档不可见。我们曾用scroll导出日志数据，导出耗时6小时，结果发现最后2小时的日志全部丢失。解决方案是改用Point In Time（PIT）API，它提供轻量级、无状态的快照机制，内存占用仅为scroll的1/20，且支持实时更新。PIT是7.10+版本的标配，但很多团队仍沿用scroll，纯粹因为文档没细读。

2.6 监控与诊断类请求：自食其力的元数据消耗

_cat、_nodes/stats、_cluster/health这类监控API，看似只读元数据，实则对集群有隐性压力。特别是_nodes/stats?level=indices，它会遍历所有索引的segment、translog、cache等详细指标，当集群有500个索引时，单次请求可触发数万次磁盘读取。我们曾将监控采集频率设为10秒，结果发现协调节点CPU 30%时间花在解析这些stats响应上。根本原因是：stats数据并非缓存，而是实时计算。优化方案是分级采集——基础健康状态（green/yellow/red）用_cluster/health（毫秒级），详细指标用_nodes/stats但降低频率（如5分钟），而索引级细节仅在告警触发时按需拉取。记住：监控本身不应成为被监控对象的负担。

2.7 Watcher与Transform：后台任务的资源契约

Watcher告警和Transform数据转换，属于ES内置的“定时作业”系统。它们在专用线程池（watcher、transform）中运行，但资源配额默认极低。一个复杂Watcher可能包含HTTP调用、条件判断、模板渲染，若未设置"throttle_period"，可能在1分钟内触发数百次，耗尽watcher线程池。Transform更甚，其checkpoint机制会持续写入internal索引，若源索引更新频繁，checkpoint频率过高会导致internal索引segment爆炸。我们的经验是：所有后台任务必须显式声明资源上限。例如，Watcher配置中强制添加"throttle_period": "5m"，Transform设置"sync": {"time": {"field": "@timestamp", "delay": "60s"}}，用delay参数人为制造缓冲区，避免瞬时压力。

提示：不要相信“默认配置”。ES的默认线程池大小、队列长度、超时时间，都是为单机开发环境设计的。生产集群必须根据请求类型重新分配资源。例如，将search线程池从默认的Math.max(1, Math.min(32, available_processors))改为固定16，防止CPU核数过多时线程竞争；将write线程池队列从1000降至200，让写入失败快速暴露，而非在队列中积压数分钟。

3. 集群层级请求调度机制与核心参数精调

ES集群不是一台超级计算机，而是一个由协调节点（Coordinating Node）、主节点（Master Node）、数据节点（Data Node）构成的分布式协作体。不同请求在集群中流动的路径截然不同，理解这条路径，是精准调优的前提。这里没有抽象模型，只有真实的数据流向和资源占用点。

3.1 请求入口：协调节点的三重过滤网

所有客户端请求（无论来自Kibana、Logstash还是自研应用）首先抵达协调节点。它不存储数据，但承担着最繁重的“大脑”工作：解析请求、路由分发、结果聚合、错误处理。协调节点对请求的处理分三层：

第一层是HTTP层过滤。ES默认开启http.compression: true，对大于3KB的响应自动gzip压缩。这能减少网络传输量，但会增加协调节点CPU负担。我们在CDN前置的场景中关闭了它，因为CDN已做压缩；而在内网直连场景中保留，节省骨干网带宽。关键参数是http.max_content_length（默认100MB），它限制单次请求体大小。曾有团队上传120MB的bulk JSON，被直接拒绝，错误提示却是400 Bad Request，排查半天才发现是此参数卡死。建议根据业务最大bulk size设为200MB，并在客户端做分块校验。

第二层是线程池准入控制。协调节点为不同请求类型维护独立线程池：search、write、management。每个线程池有size（线程数）和queue_size（等待队列长度）两个核心参数。当请求到达时，若线程池有空闲线程，立即执行；若无，则入队；若队列满，则直接拒绝（EsRejectedExecutionException）。这是集群自我保护的第一道闸门。我们曾将search.queue_size从1000调至5000，以为能缓解高峰排队，结果导致OOM——因为队列中的请求对象本身占用堆内存，队列越大，内存压力越重。正确做法是：保持queue_size适中（1000-2000），配合客户端重试机制，让失败快速反馈，而非堆积。

第三层是熔断器（Circuit Breaker）拦截。这是ES最精妙的资源保护机制。它在JVM堆内存耗尽前主动拒绝请求，避免OOM崩溃。主要有三类熔断器：

• request：限制单个请求占用的内存（默认60% heap）
• fielddata：限制fielddata cache（默认40% heap）
• request：限制所有请求总内存（默认95% heap）

其中fielddata熔断器最易触发。当执行text字段的terms聚合时，ES需将该字段所有值加载到内存构建倒排表。若字段基数高，瞬间吃光fielddata cache，触发熔断。解决方案不是调大熔断阈值，而是：1）将text字段的fielddata: true改为false，改用keyword子字段；2）对必须用text聚合的场景，显式设置"fielddata_frequency_filter": {"min": 100}，只加载出现频次≥100的词项。这比盲目调大熔断器安全十倍。

3.2 路由分发：分片定位的数学本质

协调节点解析完请求，下一步是确定该请求应发往哪些分片。这依赖于路由（Routing）算法：shard_num = (hash(_routing) + hash(_id)) % num_primary_shards。默认_routing值为文档_id，因此相同_id的文档必然落在同一分片。但业务中常需自定义_routing，例如电商订单按user_id路由，确保同一用户的订单数据集中在一个分片，聚合查询时无需跨分片合并。然而，自定义_routing是一把双刃剑：若user_id分布不均（如头部100个用户占80%订单），会导致部分分片负载过重，形成热点。我们采用“双层路由”策略：先按user_id % 100分100个逻辑桶，再将每个桶映射到物理分片，通过哈希分散热点。这需要在索引创建时预设"number_of_routing_buckets": 100，并在写入时指定routing=user_id%100。注意：routing值必须是字符串，数字需转为字符串，否则哈希结果错乱。

3.3 数据节点执行：分片级资源隔离实战

请求抵达data节点后，进入真正的执行阶段。每个分片（Shard）是Lucene的一个独立索引实例，拥有自己的内存结构（Segment、Doc Values、Fielddata）、线程池和资源配额。这里的关键是：分片不是越小越好，而是要与硬件资源匹配。一个2TB SSD上的分片，若只有1GB数据，意味着99%的磁盘空间闲置，而分片元数据、segment文件头等固定开销却一分不少。我们通过压测发现：单分片大小在20GB-50GB时，查询吞吐与资源利用率达到最佳平衡点。小于20GB，分片管理开销占比过高；大于50GB，segment merge耗时剧增，影响实时性。因此，索引生命周期管理（ILM）中，"max_size": "50gb"是黄金参数。

分片执行时，线程池是资源隔离的核心。data节点有search、write、flush、merge等线程池。其中merge线程池专用于segment合并，其size默认为Math.max(1, Math.min(4, available_processors / 2))。当磁盘IO是瓶颈时（如HDD环境），应将merge.size设为1，避免多线程争抢IO；当CPU是瓶颈时（如SSD+高聚合查询），可设为2，加速merge释放heap内存。我们曾在线上将merge.size从默认2改为1，虽然merge耗时增加30%，但查询延迟下降45%，因为CPU不再被merge抢占。

3.4 结果聚合：协调节点的内存炼狱

所有分片返回结果后，协调节点开始聚合。这是最易被忽视的性能黑洞。例如，一个size=100的搜索请求，若集群有10个分片，每个分片需返回top 100结果（共1000条），协调节点再排序取前100。内存消耗 = 1000 × 单文档元数据大小（约2KB）= 2MB。看似不大，但若size=1000，则需20MB；若聚合terms返回10000个桶，每个桶含key+doc_count+子聚合，内存轻松破百MB。ES为此提供了search.max_buckets参数（默认65535），但它只限制聚合桶数量，不限制内存。真正有效的控制是index.max_result_window（默认10000），它强制限制from+size的最大值，倒逼业务方改用search_after。我们所有生产索引都将其设为10000，并在API网关层拦截超限请求，返回明确错误码，而非让ES在协调节点OOM。

3.5 跨集群请求：远程集群的网络心跳

跨集群搜索（CCS）允许一个集群查询另一个集群的数据，语法为GET /remote_cluster:my_index/_search。这看似方便，实则引入了新的故障点：网络延迟、远程集群健康状态、认证代理开销。CCS请求的执行路径是：本地协调节点 → 远程协调节点 → 远程数据节点 → 返回。其中，远程协调节点的响应时间直接叠加到本地延迟上。我们曾因远程集群网络抖动（P99延迟从20ms升至800ms），导致本地搜索P99从150ms飙升至1s。解决方案是：1）为CCS设置独立的search线程池，避免影响本地请求；2）在elasticsearch.yml中配置cluster.remote.*.skip_unavailable: true，当远程集群不可用时，自动跳过而非报错；3）对CCS结果做缓存，因为远程数据通常变更不频繁。

注意：永远不要在协调节点上混用master角色。master节点负责集群状态管理（如分片分配、节点加入退出），需极致稳定。若协调节点同时是master，一次复杂的search请求可能占用其CPU，导致集群状态更新延迟，引发分片频繁重分配。我们的标准架构是：3个专用master节点（不存数据、不处理请求）+ N个data节点（可选启协调功能）+ M个纯协调节点（仅处理请求）。

4. 实操全流程：从请求压测到参数调优的闭环验证

纸上谈兵终觉浅，绝知此事要躬行。以下是我们在线上环境验证“集群处理不同请求”能力的完整闭环流程，每一步都有明确目标、工具、参数和预期结果。这不是理论推演，而是可直接复制的SOP。

4.1 基准压测：用Rally构建真实流量模型

ES官方压测工具Rally是唯一能模拟真实业务请求混合比的利器。它通过track（轨迹）定义数据集和请求模板，通过challenge（挑战）定义并发策略。我们为某日志分析集群设计的track如下：

{ "challenges": [ { "name": "mixed-workload", "description": "混合工作负载：60%搜索，20%聚合，15%写入，5%管理", "schedule": [ { "operation": "search-log-keyword", "warmup-time-period": 60, "time-period": 300, "clients": 50 }, { "operation": "agg-user-behavior", "warmup-time-period": 30, "time-period": 120, "clients": 10 }, { "operation": "bulk-ingest", "warmup-time-period": 30, "time-period": 120, "clients": 20 } ] } ] }

关键点在于clients参数：它不是并发线程数，而是Rally模拟的“虚拟用户”数，每个用户按固定节奏发起请求。warmup-time-period是预热期，让JVM JIT编译、OS缓存生效，避免首分钟数据失真。我们规定：所有压测必须运行至少5分钟有效数据（time-period），且预热期不少于1分钟。压测结果不看平均值，只看P95和P99延迟，因为它们反映用户体验底线。

4.2 线程池监控：从堆栈中揪出阻塞根源

压测中若发现延迟飙升，第一反应不是调参数，而是抓取线程堆栈。在协调节点执行：

curl -XGET "localhost:9200/_nodes/hot_threads?threads=10&ignore_idle_threads=false"

此命令返回CPU占用最高的10个线程的完整堆栈。我们曾发现一个典型问题：search线程池中多个线程卡在org.apache.lucene.search.TopFieldCollector.collect方法，堆栈显示它们正在等待同一个ReentrantLock。这意味着：多个搜索请求在协调节点争夺同一把锁，根源是search.max_buckets设得过大，导致全局聚合桶合并时锁竞争激烈。解决方案是将search.max_buckets从默认65535降至10000，并在业务层做分页聚合。

4.3 JVM GC调优：G1垃圾回收器的精准手术

ES 7.x默认使用G1 GC，其核心参数-XX:MaxGCPauseMillis=1000（目标停顿1秒）常被误认为“越小越好”。实测表明：设为200ms会导致GC过于频繁，吞吐量下降；设为2000ms则单次停顿过长，影响实时性。我们的黄金值是-XX:MaxGCPauseMillis=500。更重要的是-XX:G1HeapRegionSize，它决定G1的内存分区大小。默认值根据堆大小自动计算，但若堆为32GB，自动计算为1MB，而我们的SSD随机读取性能在4KB-64KB最佳，因此手动设为-XX:G1HeapRegionSize=4M，让G1的region大小匹配磁盘IO特性，GC效率提升22%。

4.4 磁盘IO优化：Linux内核参数的硬核调整

ES对磁盘IO极其敏感，尤其是translog写入和segment flush。默认ext4文件系统使用data=ordered模式，即元数据有序但数据可延迟写入，这在ES中会导致数据一致性风险。我们强制改为data=writeback，并禁用atime更新：

# /etc/fstab /dev/nvme0n1p1 /var/lib/elasticsearch ext4 defaults,noatime,data=writeback 0 0

同时调优IO调度器。NVMe SSD使用none（绕过内核调度器），SATA SSD使用deadline，HDD使用cfq。命令为：

echo 'none' | sudo tee /sys/block/nvme0n1/queue/scheduler

此外，vm.swappiness=1是铁律——ES进程内存必须锁定（bootstrap.memory_lock: true），绝不允许swap，否则一次swap操作可导致查询延迟飙升至10s以上。

4.5 网络参数加固：TCP连接的终极调优

ES节点间通信（transport）和客户端通信（http）都走TCP，网络参数直接影响吞吐。关键参数：

• net.core.somaxconn=65535：增大连接队列长度，避免SYN Flood
• net.ipv4.tcp_tw_reuse=1：允许TIME_WAIT状态的socket重用，应对高并发短连接
• net.ipv4.ip_local_port_range="1024 65535"：扩大本地端口范围，避免端口耗尽

我们曾因somaxconn默认128，在突发流量时大量连接被拒绝，错误日志显示java.io.IOException: Too many open files。调整后，单节点可稳定支撑5000+并发连接。

4.6 参数调优闭环：从假设到验证的AB测试

所有参数调整必须遵循AB测试原则。例如，要验证indices.memory.index_buffer_size（索引缓冲区）的影响：

1. 基线：设为10%，压测记录P95延迟=120ms，GC次数=8次/分钟
2. 实验组A：设为5%，压测P95=135ms，GC=5次/分钟（内存压力减小，但索引速度降）
3. 实验组B：设为15%，压测P95=110ms，GC=12次/分钟（索引快，但GC压力大）

结论：10%是平衡点。若业务写入压力大，可临时调至12%，但需密切监控GC。永远不要一次性调整多个参数，否则无法归因。我们使用Elasticsearch的_nodes/statsAPI自动化采集关键指标，每5秒记录一次，生成趋势图，让调优决策有据可依。

实操心得：压测时务必开启xpack.monitoring.enabled: true，它会自动采集集群所有指标，比手动curl高效百倍。但注意，monitoring数据本身也写入ES，需为其单独配置dedicated monitoring cluster，避免干扰业务集群。

5. 典型故障场景与根因排查速查表

再完美的设计也难逃现实世界的意外。以下是我们在生产环境中高频遭遇的5类故障，每类都附带现象→根因→排查命令→解决步骤→预防措施的完整链条，堪称ES集群的“急救手册”。

5.1 故障一：集群状态突然变黄，分片未分配

• 现象：GET /_cluster/health?pretty返回"status":"yellow"，"unassigned_shards":12
• 根因：最常见的原因是磁盘水位超限。ES默认cluster.routing.allocation.disk.watermark.low=85%，当某节点磁盘使用率≥85%，ES停止向其分配新分片；≥90%（high watermark）时，开始迁移现有分片；≥95%（flood stage）时，拒绝写入。
• 排查命令：

  # 查看各节点磁盘使用率 GET /_cat/allocation?v # 查看未分配分片详情 GET /_cluster/allocation/explain?pretty

• 解决步骤：
  1. 清理磁盘：删除旧索引（DELETE /old_index-*）或使用ILM自动rollover
  2. 临时调高watermark（仅应急）：PUT /_cluster/settings { "persistent": { "cluster.routing.allocation.disk.watermark.high": "92%" } }
  3. 强制重分配：POST /_cluster/reroute?retry_failed
• 预防措施：在ILM策略中设置"min_age": "30d"自动删除30天前索引，并配置"disk_usage_percentage": 80的告警，早于watermark触发。

5.2 故障二：搜索请求大量超时，但集群状态正常

• 现象：GET /_nodes/stats/thread_pool?human显示search线程池rejected计数持续增长，queue长度>1000
• 根因：协调节点search线程池饱和，请求在队列中等待超时（默认search.default_timeout=10s）。常见于复杂聚合或深分页。
• 排查命令：

  # 查看search线程池详情 GET /_nodes/stats/thread_pool/search?human # 查看当前活跃搜索任务 GET /_tasks?detailed=true&actions=*search*

• 解决步骤：
  1. 立即终止长任务：POST /_tasks/task_id:12345/_cancel
  2. 临时扩容线程池：PUT /_cluster/settings { "transient": { "thread_pool.search.size": 32 } }
  3. 根治：在业务层增加timeout=5s参数，并捕获TimeoutException做降级（如返回缓存结果）
• 预防措施：为所有搜索API网关配置熔断器，当P95延迟>2s时自动切断流量5分钟。

5.3 故障三：Bulk写入成功率骤降，错误日志充斥EsRejectedExecutionException

• 现象：Logstash或Filebeat日志出现大量rejected execution，写入速率从10k/s跌至1k/s
• 根因：write线程池队列满，通常是Bulk size过大或写入突增。ES默认thread_pool.write.queue_size=200，队列满即拒绝。
• 排查命令：

  # 查看write线程池状态 GET /_nodes/stats/thread_pool/write?human # 查看translog状态 GET /_nodes/stats/indices/translog?human

• 解决步骤：
  1. 降低Bulk size：从10MB降至1MB，增加客户端并发数
  2. 临时扩容队列：PUT /_cluster/settings { "transient": { "thread_pool.write.queue_size": 1000 } }
  3. 检查translog：若translog.estimated_generation_time_in_millis> 10000，说明translog写入慢，需检查磁盘IO
• 预防措施：在客户端实现动态Bulk size——根据上一批写入耗时自动调整，耗时<500ms则size×1.2，>2s则size×0.8。

5.4 故障四：节点频繁断连，master_not_discovered_exception

• 现象：节点日志出现master_not_discovered_exception，集群反复选举，状态在green-yellow间震荡
• 根因：网络分区或master节点负载过高。ES master节点需处理所有集群状态变更，若其CPU持续>90%，无法及时响应心跳，其他节点判定其失联。
• 排查命令：

  # 查看master节点状态 GET /_cat/master?v # 查看节点间ping延迟 GET /_nodes/stats/transport?human

• 解决步骤：
  1. 立即隔离高负载master节点：POST /_cluster/voting_config_exclusions/node_name
  2. 检查master节点JVM：若GC频繁，调大heap或优化GC参数
  3. 强制重新选举：POST /_cluster/voting_config_exclusions/_clear
• 预防措施：严格分离master节点，禁止其承担任何数据或协调角色；配置discovery.zen.minimum_master_nodes（ES6.x）或cluster.initial_master_nodes（ES7.x）防脑裂。

5.5 故障五：聚合结果不准确，sum值明显偏小

• 现象：GET /logs/_search中"aggs":{"total":{"sum":{"field":"bytes"}}}返回值比实际小30%
• 根因：默认情况下，聚合在分片级别执行，协调节点合并结果。若分片数据分布不均，或存在shard failure，部分分片结果丢失。更隐蔽的原因是preference参数被设为_primary，强制只查主分片，忽略副本。
• 排查命令：

  # 查看聚合执行详情 GET /logs/_search?explain=true # 检查分片状态 GET /_cat/shards/logs?v

• 解决步骤：
  1. 强制使用所有分片：在查询中添加"preference": "_local"（优先本地分片）或移除preference
  2. 启用"collect_mode": "breadth_first"，让ES先收集所有分片的顶层聚合，再深入，减少中间结果丢失
  3. 对关键聚合，启用"track_total_hits": true，验证命中文档总数是否合理
• 预防措施：对核心业务索引，禁用"index.number_of_replicas": 0，始终保留至少1副本，确保聚合结果冗余。

常见问题速查表总结：所有故障的根因90%集中在四个维度——磁盘空间、线程池、JVM内存、网络连通性。排查时按此顺序检查，80%的问题可在5分钟内定位。永远记住：ES是一个分布式系统，它的“健康”不是某个节点的状态，而是所有节点协同