Amazon AWS SQS FIFO队列sendMessage返回成功但消息未实际投递求助

看起来你遇到的是SQS FIFO队列特有的去重或消息阻塞问题——返回成功但实际没有可消费的消息，这种情况确实容易误导业务逻辑（比如你更新数据库的sent_to_sqs字段）。结合FIFO队列的特性，我整理了几个最可能的原因和对应的解决思路：

1. MessageDeduplicationId触发了SQS的自动去重 #

SQS FIFO队列默认会在5分钟的去重窗口内，自动过滤使用相同MessageDeduplicationId的消息。这时候sendMessage()会返回成功，但实际上并不会向队列中添加新消息——因为SQS认为这是重复请求，直接拦截了。

解决办法： #

• 检查你的MessageDeduplicationId生成逻辑：确保每个需要发送的新消息都有唯一的ID，比如用UUID + 业务主键的组合，避免重复生成相同ID
• 如果你的业务需要在5分钟内重复发送同一条消息（比如重试场景），不要依赖SQS的自动去重，改用客户端侧去重：自己维护一个去重缓存（比如Redis），记录已发送的ID和过期时间，避免重复调用sendMessage()

2. 消息处于"飞行中"（In Flight）的不可见状态 #

如果之前有消费者已经接收了这条消息（或者同MessageGroupId的消息）但没有调用DeleteMessage()确认处理完成，消息会进入可见性超时状态，暂时无法被获取。如果你的MessageDeduplicationId重复，SQS返回成功但实际复用了之前的那条不可见消息，自然就看不到可用消息了。

解决办法： #

• 登录AWS控制台查看队列的Messages in Flight指标，确认是否有未处理的消息
• 调整队列的Visibility Timeout设置，或者检查消费者代码，确保处理完成后及时调用DeleteMessage()
• 可以用PurgeQueue清空队列（注意：这会删除所有消息，仅用于测试场景），然后重新发送测试

3. MessageGroupId导致的顺序阻塞 #

FIFO队列对同一个MessageGroupId的消息会严格按顺序处理：如果该分组下有某条消息处于"In Flight"状态，后续同组的所有消息都会被阻塞，无法被消费者获取。这时候即使sendMessage()返回成功，消息也会被卡在队列里，直到前面的消息被确认删除。

解决办法： #

• 评估业务是否真的需要严格顺序：如果不需要，给不同的消息分配不同的MessageGroupId（比如按用户ID、订单ID拆分），分散负载
• 排查对应MessageGroupId下的卡住消息：可以通过SQS控制台的"Message ID"追踪，或者调用ChangeMessageVisibility()重置可见性超时，让消息重新可见

4. 避免误更新数据库的验证步骤 #

为了不因为SQS的特殊机制误更新数据库，建议你在收到sendMessage()成功返回后，额外做一步验证：

• 调用GetQueueAttributes API，查看ApproximateNumberOfMessages和ApproximateNumberOfMessagesNotVisible指标，确认消息是否存在
• 用ReceiveMessage API做一次短轮询（设置WaitTimeSeconds=2），尝试获取刚发送的消息，确认它能被正常读取
• 只有当验证通过后，再更新数据库的sent_to_sqs字段

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