AWS SQS问题：单条消息可见性超时前队列无法投递任何消息

嘿各位开发者朋友！刚折腾完一个AWS SQS FIFO队列的问题，已经自己搞定了～本来可以悄悄收尾，但想着说不定有人跟我遇到一样的坑，就把整个过程分享出来，希望能帮到大家😆

我的初始配置背景 #

• 主队列用的是AWS SQS FIFO类型，绑定了死信队列（DLQ）处理失败消息
• 上游是单个微服务生产者，负责往队列推送消息
• 下游部署了10个ECS容器实例作为消费者，并行处理队列消息

遇到的棘手问题 #

运行初期一切正常，但过了几天就出现两个头疼的状况：

1. 消息阻塞严重：明明消费者有空闲资源，却有大量消息卡在队列里，最后全被转到了DLQ
2. 正常消息被误判：有些消息只是遇到下游服务临时波动，重试几次就能成功，但没等故障恢复就被扔进了DLQ

我的解决步骤 #

1. 重构消息组ID分配策略 #

这是最核心的问题！FIFO队列的特性是：同一个Message Group ID的消息必须按顺序处理，一旦某条消息处理失败进入重试流程，整个组内的其他消息都会被锁定，直到这条消息被处理完成或者转入DLQ。

我之前图省事，给大部分消息都用了同一个消息组ID，结果只要有一条消息处理失败，后面同组的几十条消息全被堵死，重试几次后集体进了DLQ。

修正方案：

• 对需要严格顺序的消息（比如同一用户的操作日志），分配相同的消息组ID
• 对无需顺序的消息，直接用随机生成的消息组ID，让不同组的消息能被多个消费者并行处理，避免互相阻塞

2. 优化死信队列触发阈值 #

我之前把主队列的Maximum Receives（消息被接收的最大次数）设成了3次，但有些临时故障（比如下游服务重启）的恢复时间需要5分钟左右，3次重试的间隔加起来根本不够，导致消息还没等到恢复就被转去了DLQ。

修正方案：

• 根据业务实际的故障恢复时长，把Maximum Receives调高到10次
• 给消费者的重试逻辑加上指数退避策略：第一次重试等10秒，第二次20秒，第三次40秒……既不会频繁重试给系统加负担，也能给临时故障留出足够的恢复窗口

3. 修正消费者的消息确认逻辑 #

我排查后发现，部分消费者存在两个问题：要么提前调用了DeleteMessage API，导致后续处理失败无法重试；要么处理超时，导致消息的可见性超时到期后被重新入队，增加重试计数。

修正方案：

• 确保消费者只有在消息处理完全成功后，再调用DeleteMessage接口
• 根据消息的平均处理时间，合理设置队列的Visibility Timeout（一般设为处理时间的3倍左右），避免处理还没完成就被重新入队

最终效果 #

调整完这些配置后，消息阻塞的情况几乎消失，消费者的并行处理效率拉满，再也没有正常消息被误扔进DLQ了，完美解决问题！

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