Amazon SQS无消费者时消息进入飞行状态问题咨询

针对你遇到的问题，结合SQS FIFO队列的特性，可能的原因如下：

• 残留的长轮询连接导致隐形消费者
  SQS的长轮询机制会保持连接最长20秒，如果服务B之前异常退出、未正确关闭SQS客户端连接，SQS会判定仍有消费者在监听队列a，持续将消息推送至该无效连接。此时消息会被标记为Messages in flight，但实际无接收者处理，直到消息可见性超时到期。若可见性超时设置过长，就会出现消息长期卡在In Flight状态、服务B启动后无法消费的情况。

• 服务配置错误，意外消费队列a
  检查服务C的配置是否存在失误：如果服务C的消费者误配置了队列a的URL/ARN，启动时会意外成为队列a的消费者，将消息拉取到In Flight状态。由于服务C没有处理队列a消息的逻辑，不会主动删除消息或延长可见性超时，导致消息一直处于In Flight状态，服务B启动后无法获取该消息。

• 未关闭的其他消费者实例
  确认是否存在其他运行中的服务B实例（比如测试环境残留实例、未正常停止的容器），这些实例仍在监听队列a，会将消息拉取到In Flight状态。即使你本地的服务B未运行，远端实例会持续持有消息，导致你启动本地服务B后无法消费。

• FIFO队列消息组的锁定机制
  如果队列a使用了消息组ID，当某条消息被拉取到In Flight状态时，同消息组内的后续消息会被锁定，无法被其他消费者获取。若上述隐形消费者拉取了某消息组的消息并长期持有，同组的所有消息都会卡在In Flight状态，服务B启动后也无法消费该组内的消息。

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