应检查线程池拒绝计数并扩容bulk线程池、优化bulk批次大小与并发数、避免id热点导致分片倾斜、必要时增加节点或升级硬件。

如果您在向Elasticsearch写入数据时发现索引速度骤降，并频繁出现es_rejected_execution_exception错误，说明线程池已无法接纳新任务，请求被主动拒绝。以下是解决此问题的步骤：

一、检查线程池队列积压与拒绝计数

该步骤用于确认是否因写入并发过高或处理能力不足导致线程池饱和。通过API可实时获取各节点write线程池状态，识别active threads、queued tasks及rejected值是否已达上限。

1、执行HTTP GET请求：curl -X GET "http://your_es_host:9200/_cat/thread_pool/write?v&h=id,name,active,queue,rejected,completed"

2、观察输出中rejected字段是否持续增长，且queue值等于queue_size（如默认10000）

3、若active threads恒等于线程池size，且queued tasks长期满载，表明写入处理已严重阻塞

二、调整bulk线程池配置

该方法直接扩大批量写入任务的承载能力，适用于写入QPS稳定但单节点吞吐不足的场景。需修改配置并重启节点，确保参数生效。

1、编辑elasticsearch.yml文件，在末尾添加以下配置块：

threadpool:

  bulk:

    type: fixed

    size: 60

    queue_size: 1000

2、保存文件后，逐台重启Elasticsearch节点使配置生效

3、重启后再次调用/_cat/thread_pool/write验证size与queue_size是否更新成功

三、优化bulk请求负载分布

该方法从客户端侧降低单节点压力，避免大量小bulk请求集中涌入同一分片或节点，缓解热点与排队竞争。

1、将原始每批次100条文档的bulk请求，调整为每批次500–1000条（单请求体控制在10MB以内）

2、在应用层引入限流机制，例如使用令牌桶算法将并发bulk请求数限制在每节点≤8个并发

3、禁用客户端自动重试逻辑，改为记录失败bulk并异步重发，防止雪崩式重试加剧队列堆积

四、消除分片级写入热点

该方法针对因_id哈希不均导致多数文档路由至同一分片，造成单分片CPU与队列独占性过载的问题。

1、确认是否手动指定了_id字段：若业务使用自定义主键作为_id，且该主键具有时间/序列特征（如递增ID），则极易产生shard skew

2、临时创建测试索引，不指定_id，由ES自动生成：验证写入速率与es_rejected_execution_exception是否显著减少

3、如必须使用业务主键，改用hash+salt方式构造_id，例如对原始ID拼接随机字符串后再取MD5，提升shard分散度

五、扩容写入资源承载能力

该方法通过增加物理资源维度提升整体吞吐，适用于长期高负载、配置调优已达瓶颈的生产环境。

1、向集群新增至少一个数据节点，确保分片自动再平衡后写入压力分散到更多节点

2、将现有数据节点升级为更高vCPU规格实例（如从8核升至16核），使write线程池size自动提升（默认=CPU核数）

3、检查磁盘IO等待时间（iostat -x 1），若%util > 95%或await > 50ms，更换为更高IOPS的SSD存储设备