关于SQS绑定DLQ后Maximum receives触发消息入DLQ规则的问询

SQS DLQ 触发规则与常见疑问解答 #

1. DLQ 核心触发逻辑

SQS 会为每个消息维护一个ApproximateReceiveCount属性，每一次消费者从队列中拉取到该消息，这个计数就会+1，和消费成功/失败、是否主动返回错误无关。
当同时满足以下两个条件时，消息会被自动投递到绑定的DLQ：

• 消息的ApproximateReceiveCount等于你配置的Maximum receives阈值
• 消息被消费者拉取后没有被主动删除，等到可见性超时（或者消费者主动将消息可见性设为0）回到主队列时，SQS 会校验计数，触发DLQ投递

2. 对应疑问解答

疑问1：Maximum receives 设为1时，首次消费失败是否直接进DLQ？

是的，符合触发条件的情况下会直接投递：
你配置阈值为1时，消息第一次被Spring Service拉取，ApproximateReceiveCount变为1，如果消费失败你没有主动删除这条消息，等消息可见性超时回到主队列时，SQS 检查发现计数已经达到阈值，就会直接将消息移到DLQ，不会再允许被第二次拉取。

疑问2：是否只需要调高Maximum receives就能给Spring Service更多重试机会？

默认情况下是可以的，但有几个前提需要注意，避免出现不符合预期的情况：

• 如果你没有在Spring侧配置本地重试（比如@Retryable注解实现的进程内重试），所有重试都依赖SQS层面的消息回退：那么调高Maximum receives就等于增加消费重试次数，比如设为3就允许最多3次拉取消费。
• 如果你在Spring侧配置了本地重试：本地重试阶段不会将消息放回队列，也就不会增加ApproximateReceiveCount，总重试次数等于「本地重试次数 × Maximum receives 配置值」。
• 必须保证主队列的Visibility Timeout配置大于你Spring服务消费单条消息的最长耗时，否则消息还没处理完就因为可见性超时自动回到队列，计数会异常增加，导致提前进入DLQ。

补充注意点

• 如果你希望消费失败后立即重试，不需要等完整的可见性超时，可以在消费逻辑捕获到异常时，主动调用SQS API将对应消息的可见性设为0，消息会立即回到队列触发下一次重试。
• DLQ的消息保留时间建议配置得比主队列更长，方便后续排查问题时回溯异常消息。

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