Magento 2 重新索引或批量更新商品时出现 HTTP 429、es_rejected_execution_exception 或 bulk queue capacity exceeded。它表示搜索集群当前无法按速度处理新请求并主动拒绝，不等同于普通认证失败。无限重试会继续压垮集群，必须先降低输入或提升真实处理能力。

确认拒绝发生在 bulk、search 还是 write

SEARCH_ENDPOINT='搜索服务地址'
curl -sS \"$SEARCH_ENDPOINT/_cat/thread_pool?v\"
curl -sS \"$SEARCH_ENDPOINT/_nodes/stats/thread_pool,jvm,fs?pretty\"
curl -sS \"$SEARCH_ENDPOINT/_cluster/health?pretty\"

观察 active、queue 与 rejected 的增长，结合 JVM heap、GC、CPU、磁盘 I/O 和可用空间。只看一次 429 无法判断是短峰值还是持续容量不足。

先避免多个全量索引同时运行

部署、手工 reindex、Cron 增量索引和批量商品导入可能同时向集群写入。检查进程与 cron_schedule，保证同一环境只有预期的索引任务。不要在全量重建卡住时反复启动新的 reindex。

调整 Magento 批次，而不是只扩大服务端队列

搜索索引批次过大，会制造单次内存和队列峰值；过小又会增加往返。根据商品文档大小和集群吞吐逐步调整 batch size，并记录每批耗时、拒绝率和堆内存。直接把 OpenSearch queue 调得很大可能只把拒绝变成长时间排队，最终触发超时和更高内存。

分片设计和节点资源决定实际吞吐

大量小分片会增加管理和合并成本，单个巨大分片又限制并行。Magento 索引数量还受 Store View 和索引前缀影响。检查当前主分片、replica、文档数与段合并，不要照搬另一站点的分片数量。

磁盘接近水位、JVM 持续高 GC、节点间网络慢时，增加 PHP 超时不能解决。先释放安全空间、修复节点健康或扩容，再执行全量索引。

客户端重试必须有退避和上限

对 429 可采用指数退避与有限重试，但重试批次必须可幂等，且不能所有 worker 同时立即重试。加入随机抖动能避免惊群。若达到上限，应清楚记录失败批次，让后续恢复而不是静默丢文档。

恢复后单独运行 catalogsearch_fulltext，确认 rejected 计数不再快速增长，再修改一个商品验证增量索引。前台还应测试搜索、排序和筛选，确保不是“索引命令成功但部分 bulk 被拒绝”。