如何限制AWS DLQ的消息重驱次数？

首先明确：原生SQS的DLQ重驱到源队列功能，不支持直接限制单条消息的重驱次数——它只会按照配置的批量大小/触发条件，把DLQ里的消息重驱到源队列，没法追踪单条消息的重驱次数，也没法在达到次数后自动停止重驱。

你想到的Lambda调度器方案完全可行，而且是实现这种「有限次数间隔重驱」需求的标准做法，下面给你细化具体落地步骤：

• 配置调度触发：用EventBridge（原CloudWatch Events）创建定时规则，按你需要的重驱间隔（比如5分钟、10分钟）触发Lambda函数。
• Lambda核心逻辑：
  1. 调用SQS的ReceiveMessage API批量拉取DLQ中的消息（注意设置合理的MaxNumberOfMessages和WaitTimeSeconds参数）。
  2. 遍历每条消息：
     • 检查自定义属性（比如你提到的maxAttempts，或者更直观的retry_count）：
       • 如果没有这个属性，说明是第一次进入DLQ，初始化值为1；
       • 如果当前次数小于3，递增次数后，调用SendMessage把消息发送回源SQS队列；
       • 如果已经达到3次，直接标记这条消息需要被删除（或者归档到S3等持久存储留底）。
  3. 调用DeleteMessageBatch API，把DLQ中已处理完成（不管是重驱还是归档）的消息删除，避免重复处理。
• 关键细节：
  • 确保源Lambda处理逻辑的幂等性：重驱的消息可能被重复处理，业务逻辑要能识别重复消息（比如用消息ID作为幂等键）。
  • 自定义属性初始化：如果是SQS自动转消息到DLQ，源Lambda在处理失败时，可以在捕获异常后手动给消息添加retry_count属性再扔到DLQ；如果是SQS自动转的无属性消息，调度Lambda要默认初始化次数为1。
  • 异常容错：Lambda执行过程中如果出现异常，要保证消息不丢失——可以设置Lambda的重试次数，或者让处理失败的消息暂时留在DLQ，等待下一次调度处理。

另外还有个替代思路：把DLQ设置成延迟队列（配置DelaySeconds），用Lambda直接触发DLQ，但这种方式仍需结合自定义属性判断重试次数，本质和调度方案逻辑类似，只是触发方式从定时变成了消息驱动。

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