AWS Elasticsearch是否有操作数量限制？如何调优支撑高并发PUT请求？

Elasticsearch 每秒可承载的PUT操作数没有固定硬上限，实际承载能力完全由集群规格、索引配置、请求模式决定，不存在通用的统一阈值。

这个量级的请求会不会触发服务故障完全取决于你的集群配置：

• 如果你使用的是单节点2核4G这类最低配的开发测试实例，单条PUT直写的场景下大概率会打满节点CPU、占满写入队列，触发请求拒绝、节点OOM甚至集群不可用。
• 如果你使用的是标准生产配置集群：至少3个独立数据节点，单节点规格8核32G以上，搭配基础的写入优化配置，15000次/秒的PUT属于非常常规的业务负载，完全不会导致服务故障。

以下都是生产环境验证过的有效优化手段，不需要做过度的参数魔改：

集群配置侧（针对AWS托管ES/OpenSearch服务） #

• 数据节点优先选r系列、i系列的计算/存储优化实例，不要选T系列突发性能实例跑生产写入负载；单节点堆内存和磁盘数据量比例不要超过1:30，磁盘使用率长期超过85%时要及时扩容节点。
• 生产集群必须配3个独立的专用主节点，主节点规格选4核8G以上同代实例即可，不要让主节点承担数据写入、查询负载，避免主节点不稳定触发集群脑裂。
• 不要为了提升写入速度把索引副本数设为0，生产环境至少保留1个副本，避免单节点故障丢数据。
• 不要随意修改默认写入线程池的核心线程数，单节点写入队列长度可以根据峰值情况调整到1000-2000，减少不必要的请求拒绝。

索引配置侧 #

• 优先用Bulk批量接口替代单条PUT请求，单次Bulk请求大小控制在5MB-15MB区间，单批次写入文档数控制在1000-5000，这个优化项通常能直接把写入吞吐量提升5-10倍，是收益最高的优化手段。
• 根据业务实时性要求调整refresh_interval参数：如果不需要1秒级的近实时搜索，可以把默认的1s调整为30s-60s；遇到突发写入峰值时可以临时把参数设为-1完全关闭刷新，等峰值过去后再调回正常值，触发一次段合并即可。
• 关闭非必要功能：不需要算分的场景可以设置index.codec: best_compression提升压缩率，不要给不需要检索的字段建立倒排索引，非必要不要存储冗余的_source字段。
• 合理规划分片数：单分片数据量控制在20GB-50GB区间，不要创建大量小于1GB的小分片，也不要创建单分片超过100GB的超大分片。对应15000次/秒的写入场景，总分片数（含副本）控制在24-48个即可，过多分片会额外消耗集群调度资源拉低写入效率。
• 应对可预见的写入峰值时，可以临时把索引副本数调整为0，等峰值过去后再恢复副本配置等待数据同步，该操作可以临时提升近一倍的写入能力。

请求侧 #

• 客户端配置合理的重试逻辑，重试间隔增加随机抖动，避免集群故障恢复瞬间所有请求同时打到集群造成雪崩。
• 控制单文档大小，普通业务文档尽量控制在100KB以内，超过1MB的超大文档会显著拉低集群整体写入吞吐量。
• 业务允许的前提下尽量使用ES自动生成的文档ID，不要使用时间戳、自增ID这类有序的自定义主键，能减少分片内部的段合并开销。

注意：所有配置调整都要先在测试环境完成压测验证后再上线生产，不要直接在生产集群修改参数。AWS托管ES本身自带集群保护限流机制，只要预留30%左右的CPU、内存资源冗余，15000次/秒的写入负载可以长期稳定运行，不需要做过度的参数调优。

内容的提问来源于stack exchange，提问作者Abhijith Rao