AWS标准SQS队列多数消息未被Lambda消费反而消失问题咨询

以下是基于你提供的配置和现象的核心根因分析及排查步骤：

核心根因（匹配你调整Maximum Receives后现象好转的特征） #

你最初将死信队列的Maximum Receives设置为1，意味着任意消息只要被Lambda拾取后处理失败1次，就会直接被投递到死信队列，不会回到主队列重试，这是你看到大量消息「消失」的最常见原因：

• Lambda作为SQS事件源消费者时，仅当函数执行无任何异常、正常退出时，才会自动调用SQS的DeleteMessage接口删除消息
• 若Lambda执行抛出异常、超时、或被强制终止，消息会被退回主队列，接收计数+1，达到Maximum Receives阈值后直接进入DLQ，不会再出现在主队列的可见消息列表中

关键排查步骤 #

1. 核查死信队列消息存量
   直接进入你绑定的DLQ控制台，查看待消费消息数，绝大多数「消失」的消息都会存放在这里。
2. 核对SQS CloudWatch指标
   查看以下SQS监控指标确认消息流向，AWS SQS不会凭空丢弃消息：

• NumberOfMessagesSent：你发送到主队列的总消息数
• NumberOfMessagesDeleted：被正常消费后删除的消息数
• NumberOfMessagesSentToDeadLetterQueue：被投递到DLQ的消息数
• ApproximateNumberOfMessagesNotVisible：处于飞行中状态（已被Lambda拾取、尚未删除也未超出可见性超时）的消息数
  以上几个指标的总和应该和你发送的消息总数匹配。

3. 排查Lambda静默失败问题
   检查你的Lambda代码逻辑，是否存在全局异常捕获逻辑吞掉了所有错误，没有向外抛出异常：
   这种场景下Lambda会判定函数执行成功，自动删除消息，但你实际的业务处理逻辑并没有执行完成，也不会产生错误日志，就会出现「消息凭空消失、无任何日志记录」的现象。
4. 核对Lambda超时配置
   确保Lambda的函数超时时间小于SQS的可见性超时，你当前SQS可见性超时为2分钟，建议将Lambda超时设置为90秒，避免Lambda尚未执行完成，消息可见性超时就被退回队列，导致接收计数快速累加，提前进入DLQ。
5. 查看Lambda错误日志
   在CloudWatch Logs中筛选ERROR、Timeout、Exception级别的日志，确认是否存在你之前遗漏的执行报错、内存不足、运行超时等异常记录。

优化建议 #

如果你的业务场景允许消息重试，建议将Maximum Receives调整为5-10次，同时给Lambda添加足够的错误捕获和日志打印逻辑，避免静默失败导致的消息异常丢失。

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