如何基于错误类型条件性地将AWS SQS消息移入DLQ？

AWS SQS原生不支持直接根据错误类型条件性转移消息到死信队列（DLQ），默认仅通过maxReceiveCount阈值触发转移。但可以通过以下几种方案实现你的需求：

1. 消费端自定义错误处理逻辑 #

在消息消费代码中直接判断API返回的错误类型，针对性处理：

• 当捕获到5XX类临时错误时：
  • 不调用DeleteMessage删除消息，而是手动调用SendMessage将消息重新发送回源队列（可通过DelaySeconds参数设置重试间隔，避免高频冲击API）。
  • 同时调用ChangeMessageVisibility调整消息的可见性超时，确保在重试间隔内不会被其他消费者重复获取。
• 当遇到非5XX类错误（如4XX业务错误、处理逻辑异常）时：
  • 直接放弃处理，让消息的ReceiveCount自然累加，直至达到maxReceiveCount后自动移入DLQ。

注意：需利用SQS的MessageDeduplicationId做好消息去重，避免重复发送导致的重复处理；同时建议设置兜底的最大重试次数，防止API长期故障导致消息无限循环积压。

2. 结合Lambda与手动DLQ转移 #

如果使用Lambda作为SQS的消费者：

• 在Lambda函数内部捕获API调用的错误类型：
  • 若为5XX错误，抛出特定异常（或不做额外处理），让Lambda将消息重新放回源队列（需确保Lambda事件源映射的批量失败处理逻辑配置正确）。
  • 若为非5XX错误，直接调用SQS的SendMessage接口将消息手动发送到DLQ，随后删除源队列中的对应消息，绕过SQS的自动转移机制。

这种方式将DLQ的转移逻辑完全由业务代码控制，灵活性更高。

3. 用Step Functions编排重试与分流 #

借助AWS Step Functions构建状态机，实现更精细化的流程控制：

• 状态机第一步：从SQS获取消息并调用目标API。
• 根据API返回结果分支：
  • 5XX错误：进入重试状态（可配置无限重试、指数退避间隔），重试后回到API调用步骤。
  • 非5XX错误：调用SQS接口将消息发送到DLQ，完成流程。
• 处理成功：删除源队列中的消息，结束流程。

这种方案适合复杂的重试逻辑场景，状态机自带的重试、错误分支功能可以减少业务代码的复杂度。

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