搜索页偶尔空白，Magento 日志里出现 OpenSearch 429。429 不是“接口不存在”，而是集群在当前压力下主动拒绝请求。先分清被拒绝的是前台 search、批量 bulk 索引，还是触发了内存保护，处理方式完全不同。
保留429响应体，它会告诉你拒绝类型
日志不要只截状态码。响应中的 rejected_execution_exception、线程池名称或 circuit breaker 信息能直接指向资源。同步记录当时节点 CPU、JVM heap、磁盘水位、pending tasks 和 thread pool rejected 计数。
curl -s http://opensearch:9200/_cluster/health?pretty
curl -s http://opensearch:9200/_cat/thread_pool/search,write?v
curl -s http://opensearch:9200/_cat/nodes?v&h=name,cpu,heap.percent,ram.percent,disk.avail命令应在受控网络并使用正确认证。不要把管理端口暴露到公网。
看429发生在reindex还是用户搜索高峰
如果每次全量 reindex 都出现 write/bulk rejected，降低批次并错峰执行，检查是否同时有多个索引任务。若是 search 线程池拒绝，分析慢查询、聚合字段和机器人流量。商品属性大量设置为 searchable/filterable，会显著放大查询与索引成本。
再查看索引数量、主分片和副本分布。小目录拆成大量分片会浪费 heap，大目录只有一个热点分片又会让单节点吃满。不要直接照搬别人的 shard 数，先看当前文档量、分片大小和节点数，再规划新索引并通过 Magento 的重建流程切换 alias。
磁盘接近水位、分片过多或副本不可分配时，简单增加重试只会把更多请求压回集群。先恢复集群健康，再决定扩节点、调 shard、清理旧索引或优化查询。
应用重试必须有边界
对可重试的查询使用短暂指数退避和随机抖动，限制次数；不要立即无限重试。前台还应给出可理解的降级结果，而不是把异常吞掉后展示“没有商品”，否则业务会误判为搜索索引为空。
扩容后也要复测同等负载，观察 rejected 计数是否继续增长、P95 查询延迟和 reindex 用时。真正解决 429，是让峰值请求量、查询成本和集群容量重新匹配，而不是把日志级别改低。
最后把前台搜索和后台索引的容量指标分开设告警：集群健康为 green 也可能持续拒绝高峰查询。至少监控 heap、GC、磁盘水位、search/write rejected、队列长度和慢查询。这样下一次接近极限时能提前扩容或限流，而不是等客户看到空白页才发现。
