如何避免SQS重复触发Lambda 解决异步重试与批量处理问题

问题根因 #

• 初版handler未等待异步任务执行完成就提前调用callback返回，Lambda运行时会在回调触发后冻结执行环境，未跑完的异步任务被强制中断，SQS收不到对应消息的处理成功确认，触发重试逻辑，表现为多次触发、请求ID不同的超时类重试特征。
• 第二版实现使用Promise.all等待所有任务完成，解决了提前返回的问题，但采用全成则成、一败全败的判定逻辑：单条消息处理失败会导致整批消息全部被标记为处理失败，哪怕其余消息已经执行成功，也会随失败消息一起被SQS重新投递，产生重复执行问题。
• 将批处理大小设为1虽然能规避单条失败影响整批的问题，但会大幅降低Lambda吞吐效率，提升SQS请求调用成本，无法发挥批量投递的性能优势，不是最优解。

优化方案 #

SQS与Lambda的原生集成默认采用整批确认机制：handler正常返回则整批消息被确认删除，handler抛出错误则整批消息重新入队。要兼顾批量处理性能和单条失败隔离，只需要开启SQS事件源的部分批次失败报告能力，配合代码层单条任务的异常捕获，即可实现「成功消息正常删除、仅失败消息重试」的效果，不需要把批大小改为1。

1. 代码改造：使用Promise.allSettled做单条异常隔离，返回标准批失败响应 #

Promise.allSettled会等待所有任务执行完成（无论成功失败），不会因为单条任务失败提前进入reject状态，配合Lambda要求的batchItemFailures响应格式，明确告知SQS哪些消息处理失败需要重试，其余成功的消息会被正常删除。

exports.handler = async function (event, context) {
  // 等待所有任务执行完成，不因为单条失败中断
  const taskResults = await Promise.allSettled(
    event.Records.map(async (message) => {
      try {
        await runAsyncService(message.body)
        return { id: message.messageId, success: true }
      } catch (err) {
        console.error(`消息${message.messageId}处理失败`, err)
        return { id: message.messageId, success: false }
      }
    })
  )

  // 提取所有处理失败的消息ID
  const batchItemFailures = taskResults
    .filter(item => !item.success)
    .map(item => ({ itemIdentifier: item.id }))

  console.log(`批次处理完成：共${event.Records.length}条，成功${event.Records.length - batchItemFailures.length}条，失败${batchItemFailures.length}条`)

  // 按规范返回失败条目，SQS仅会重试列表内的消息
  return { batchItemFailures }
}

注意：async模式的handler不要混用callback、context.succeed()，直接return对应结果即可，混用容易导致运行时状态判定异常，出现提前终止、重复执行的问题。

2. 配置适配：在getlift/lift队列配置中开启对应能力 #

在队列配置中开启部分批次失败报告，同时调整合理的批大小、超时、重试参数即可：

constructs:
  business-queue:
    type: queue
    # 开启部分批次失败报告，支持单条消息粒度的重试判定
    reportBatchItemFailures: true
    # 批大小不需要设为1，可根据单条消息平均处理耗时设置为5-10，兼顾吞吐量和失败影响范围
    batchSize: 10
    # Lambda超时时间需大于单批任务的最长预估处理耗时，避免超时导致整批重试
    timeout: 30
    # 配置最大重试次数，超过次数的失败消息自动投递到死信队列，避免无限重试
    maxReceiveCount: 3
    deadLetterQueue: true

3. 配套优化建议 #

• 业务侧runAsyncService逻辑需要做幂等校验，即便极端场景下出现重复投递，也不会产生重复写入、重复操作等业务异常。
• 可给单条任务增加合理的超时控制，避免某条消息长时间卡住拖慢整批处理进度。
• 死信队列建议配置对应的告警，及时处理多次重试失败的异常消息，避免业务消息丢失。

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