多生产者写入同一标准SQS相关问题：消息顺序、限流阈值、饥饿规避

1. 多生产者同时写入的影响及消息顺序变化 #

• 写入性能层面：Standard SQS本身为分布式架构，支持近乎无限的TPS水平扩展，2个及以上单实例10k TPS的生产者同时写入时，只要没有超出账户默认限流阈值，不会对写入可用性造成负面影响，写入延迟基本维持在毫秒级
• 消息顺序层面：Standard SQS本身不提供严格的消息顺序保证，即便单个生产者按序发送，也存在小概率消息乱序的情况。多生产者同时写入时，不同生产者发送的消息会被SQS的分布式节点随机调度存储，消费时无法保证不同生产者的消息按照发送时间排序，同一生产者的消息也可能出现乱序。如果业务需要严格顺序，需要切换到FIFO SQS，单分区FIFO SQS最高支持3000 TPS写入，多分区可水平扩展。

2. Inflight消息阈值对应的故障触发条件 #

• 首先澄清：120000是Standard SQS每个队列的默认最大inflight（已被消费者接收但还未删除/未超时可见）消息数，属于软限制，不会直接触发队列故障
• 实际影响：当inflight消息数达到120000后，后续消费者的ReceiveMessage请求会直接返回空响应，不会报错，但消费者无法拉取到新消息，直到有存量inflight消息被删除或者可见性超时重新回到队列。不存在直接导致队列写入故障的inflight阈值，写入操作和inflight消息数完全独立，只要写入没触发限流就不会失败。
• 理论故障阈值：只有当消费速度长期远低于写入速度，队列消息堆积时长达到配置的消息保留上限（默认4天，最大可配置为14天），超过保留期的消息会被自动删除，但不会导致队列不可用。

3. 生产者饥饿问题规避方案 #

Standard SQS本身的写入调度是公平的，默认不会出现生产者饥饿，通常所说的饥饿是指部分生产者请求被限流无法写入的情况，对应规避方案如下：

• 提前申请上调SQS队列的写入限流阈值：如果默认限流不能满足总写入TPS需求，提前提交工单上调对应队列的TPS限制
• 所有生产者统一实现指数退避重试逻辑：遇到ThrottlingException错误时，按照1s、2s、4s、8s的间隔指数退避重试，重试次数建议配置5-10次，避免瞬时限流导致请求失败
• 批量写入优化：生产者使用SendMessageBatch接口批量发送消息，单批次最多10条、总大小不超过256KB，既可以降低请求触发限流的概率，也能降低请求成本
• 削峰处理：如果不同生产者的流量波动大，建议在生产者端加本地缓冲队列削峰，避免瞬时流量超出限流阈值

4. SQS限流阈值说明 #

以下为Standard SQS的默认值，不同AWS区域可能有细微差异，所有阈值都可以通过工单申请上调：

• 写入操作（SendMessage/SendMessageBatch）：默认每个队列每秒支持30000次操作，如果是批量发送，每批次算1次操作，30000次操作最高可以支持每秒30万条消息写入
• 读取操作（ReceiveMessage/DeleteMessage/ChangeMessageVisibility）：默认每个队列每秒支持30000次操作
• 单条消息最大大小：256KB，超过的话需要用对象存储服务保存大消息，SQS仅存储消息引用
• 消息保留周期：最小1分钟，最大14天，默认4天

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