AWS MSK触发的Lambda消费者处理完消息后仍持续被调用问题排查

你提到的两个场景均会触发该无报错重复消费现象，具体分析和排查方案如下： #

场景验证 #

• Lambda执行超时：即使日志中无显式超时记录也可能发生。如果函数在执行完全部业务逻辑、即将提交消费offset的前一刻触发超时，MSK触发器收不到消费成功的响应，就会判定消费失败触发重试。部分低采样率的日志配置也会漏抓超时日志，建议直接查看CloudWatch Metrics中该函数的Duration指标，确认是否存在调用时长触达配置超时阈值的情况。
• 消息体量过大：Lambda消费MSK默认存在单条消息最大1MB的限制，若消息超过该阈值，会触发自动重试，且不会生成明确的消费失败报错，表现为持续重复拉取同一条消息。

其他高频触发原因 #

除上述两个场景外，Node.js runtime的Lambda消费MSK出现无报错重复消费还有两个常见诱因：

• 异步逻辑未等待完成：SES发信、查询收件人名单等操作均为异步调用，如果代码未添加await等待异步操作完成就提前返回，函数会提前终止，offset不会提交，导致消息被重复拉取。
• 消费者组配置异常：如果MSK集群对应消费者组的auto.offset.reset配置异常，或你在代码中手动修改了offset提交逻辑，也会导致offset未正常提交，触发重复消费。

排查与修复步骤 #

1. 先查看CloudWatch指标：核对该Lambda的Duration、Errors、Throttles指标，确认是否存在隐藏的超时、限流情况；同时查看MSK对应消费者组的lag指标，若lag持续不下降，说明存在未提交的消息。
2. 代码逻辑校验：给消费逻辑添加offset打印日志，确认是否重复拉取相同offset的消息；同时检查所有异步操作是否都添加了await，避免Promise pending状态下函数提前退出。
3. 配置优化：调整Lambda超时时间为平均执行时长的3倍以上，预留足够执行buffer；给MSK触发器添加重试次数限制，避免无限重试，优化后的配置参考如下：

notificationsKafkaConsumer:
    handler: src/consumers/notifications.consumer
    events: 
      - msk: 
          arn: ${ssm:/kafka/cluster_arn~true}
          topic: "notifications"
          startingPosition: LATEST
          maximumRetryAttempts: 3 # 最大重试3次
          batchSize: 5 # 降低单批次消费数量，避免批量处理超时

4. 消息校验：排查MSK的notifications主题是否存在超过1MB的异常大消息，清理后观察消费是否恢复正常。

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