AWS SQS DLQ消息重投递常见实践及毒消息循环规避问题咨询

以下是可落地的计数防循环方案以及配套的行业常见实践：

毒消息重投递计数实现方案 #

你提到的无限循环问题可以通过自定义消息属性/消息体嵌入计数的方式解决，两种常用实现逻辑一致，仅计数存储位置不同：

• 自定义消息属性方案（更推荐，不侵入业务消息体）
  SQS原生的ApproximateReceiveCount属性仅统计单条消息在当前队列的接收次数，无法跨DLQ、原业务队列累计重投递次数，因此你可以在重投递Lambda中新增自定义属性处理逻辑：
  1. 每次Lambda从DLQ拉取到消息后，优先读取消息自定义属性中的x-dlq-retry-count，无该属性时默认值为0
  2. 若计数值已达到你预设的最大重试阈值（如2次），直接将消息写入终极错误存储（如专门的归档SQS队列、S3对象存储、DynamoDB表均可），不再重投递
  3. 若未达到阈值，将x-dlq-retry-count值+1后作为自定义属性附加到消息上，重新投递回原业务队列
• 消息体嵌入计数方案（适配属性透传失效场景）
  若你的业务消费逻辑会丢弃消息自定义属性，可以将计数字段嵌入消息体的固定扩展字段中，例如在所有消息的顶层加__retry_meta对象存储dlq_retry_count值，逻辑和自定义属性方案完全一致。

配套生产级实践建议 #

• 全局重试次数统一管控：将原业务队列触发DLQ的maxReceiveCount阈值，和DLQ侧的重投递阈值合并计算，保证单条消息全局最多重试次数符合你的业务容错要求（例如原队列最多接收3次失败进DLQ，DLQ最多允许2次重投递，全局最多尝试5次，符合常规业务容错标准）
• 增加退避延迟逻辑：重投递时可以根据x-dlq-retry-count的值设置不同的延迟时间，比如第一次重投递延迟1分钟，第二次延迟10分钟，避免瞬时故障导致的无意义重复投递
• 禁止直接丢弃超限消息：所有达到重试阈值的毒消息必须完整保留原始内容、重试次数、每次处理的错误日志，方便后续人工排查问题、补发业务请求

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