防抖S3通知触发Lambda：实现特定文件夹变更仅执行一次任务

针对你遇到的S3批量文件变更导致任务重复执行的问题，这里有两个实用的解决思路：

方案一：SQS + Lambda 延迟合并处理 #

这是最常用的批量消息合并方案，核心是用SQS攒消息，再让Lambda延迟处理同一批的消息：

• 配置S3事件通知，将目标文件夹的所有变更事件（比如ObjectCreated类）发送到同一个SQS标准队列
• 给Lambda配置SQS触发器，设置以下参数：
  • 批量处理大小：设为最大值1000（根据你的消息量调整）
  • 触发延迟：设置10-15秒（确保同一批上传的文件消息都能进入同一个Lambda执行实例）
• 在Lambda代码里做两步处理：
  1. 提取所有消息中的S3文件夹路径（比如从s3://bucket/path/to/folder/中截取到文件夹部分）
  2. 对文件夹路径去重，每个唯一文件夹只执行一次任务
• 额外保障：给任务加幂等标识，比如用文件夹路径 + 当天日期小时作为唯一键，即使重复触发也不会重复执行任务

方案二：Lambda + DynamoDB 防抖处理 #

如果不想用SQS，也可以用DynamoDB做请求防抖：

• 直接用S3事件触发Lambda
• 在Lambda里初始化DynamoDB客户端，创建一张用于记录触发状态的表（主键设为文件夹路径，属性包含last_trigger_time）
• 处理逻辑：
  1. 从S3事件中提取目标文件夹路径
  2. 查询DynamoDB，看该文件夹最近10秒内是否有过触发记录
  3. 如果有，直接返回，不执行任务；如果没有，更新触发时间并执行任务
• 注意：给DynamoDB的记录设置TTL（比如15秒），自动清理过期的触发记录，避免表数据膨胀

关键注意事项 #

• 事件过滤：在S3事件通知里只订阅你需要的事件类型（比如只选ObjectCreated:Put和ObjectCreated:CompleteMultipartUpload，排除ObjectCreated:Copy这类不需要的）
• 延迟时间调整：根据你的实际批量上传时长调整延迟，确保同一批文件的消息都能被合并
• 错误重试：如果Lambda执行失败，SQS会自动重试，要确保任务是幂等的，避免重试导致重复执行

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