AWS Lambda重复触发问题求助：S3 PUT触发重复处理同个.zip文件

核心原因推测 #

这种重复处理的情况，大概率是S3事件重复投递导致的：S3在向Lambda发送PUT事件时，可能因网络延迟、Lambda响应超时（比如CloudWatch日志未捕获到的短暂超时）等原因，重复发送了同一事件，触发了另一个Lambda实例。而当前处理逻辑中，从开始解压到完成原文件移动之间存在时间窗口，第二个实例启动时原文件还未被移走，因此再次执行了完整处理流程。

另外，CloudWatch仅显示一组日志，可能是第二个实例的日志未被及时捕获（比如实例快速退出或日志投递延迟），或者两次执行的日志被合并到了同一个流中但未被留意到细节差异。

可行的解决办法 #

1. 实现分布式幂等锁（最可靠） #

用DynamoDB做幂等校验，处理前先锁定当前文件：

• 处理开始时，尝试向DynamoDB写入一条记录，主键设为S3文件的bucket/key，附加文件的ETag（确保是同一版本的文件），用条件表达式attribute_not_exists(id)保证只有第一次写入成功。
• 如果写入失败，直接退出函数（说明已有实例在处理该文件）；如果写入成功，继续执行解压、移动文件流程，处理完成后更新记录状态为已完成。

2. 优化文件处理的原子性窗口 #

缩短原文件存在于触发目录的时间，减少重复触发的窗口：

• 第一步先把原zip文件转移到临时处理目录（比如复制到PROCESSING/xxx.zip，再删除原文件），之后再执行解压操作。这样后续触发的实例看到原目录下没有目标文件，就会直接跳过。
• 注意：S3没有原生重命名功能，需要用CopyObject+DeleteObject组合操作，这两步之间仍有极短窗口，配合幂等锁使用效果更佳。

3. 调整Lambda触发器的重试策略 #

在Lambda的S3触发器配置里：

• 降低事件重试次数（比如设为0次），避免S3因未收到确认而重复投递事件。
• 开启批量处理并设置合理的批次大小，减少单文件触发的频率（单文件场景下作用有限，但能优化多文件场景的稳定性）。

4. 增加处理前置校验 #

在函数开头添加简单校验：检查PROCESSED目录是否已存在同名文件，若存在则直接退出。但需注意S3的最终一致性特性，可能出现刚移动完文件但校验时仍未同步的情况，需配合短时间重试逻辑。

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