如何避免S3向Lambda发送同一文件的重复并行触发事件

先直接回答你提的两个核心问题：

1. S3事件没有原生的阈值配置可以避免同一文件的多次触发，S3的ObjectCreated类事件触发规则为：每次针对对象的成功写入操作（含首次创建、覆盖更新、分片上传完成）都会独立发送一次事件，不支持按对象Key去重、也不支持同Key短时间内多次写入合并为一次事件的配置。
2. S3不存在仅在文件首次创建时触发的原生事件类型，所有ObjectCreated相关的事件都会同时覆盖首次创建和覆盖更新的场景，S3本身不会在事件中区分本次写入是新增还是覆盖操作。

你当前使用的head_object检查后再创建文件的逻辑属于非原子操作，在毫秒级并发场景下会出现竞态：多个进程同时执行head_object都判断文件不存在，之后同时执行写入操作，最终导致同Key被多次写入、触发多次Lambda事件，这种客户端侧的先查后写逻辑在高并发场景下无法避免重复写入问题。

按改造成本从低到高推荐以下方案：

方案1：改用S3原子条件写入（最优，改造成本最低） #

直接替换现有写入逻辑，使用S3原生支持的If-None-Match: *条件参数执行PUT操作，该判断是S3服务端原子执行的：只有指定Key的对象不存在时，写入才会成功，对象已存在时会直接返回412错误，从根源上避免同Key被并发重复写入。
修改后的代码示例如下：

try:
    s3_client.put_object(
        Bucket=trigger_bucket,
        Key=trigger_file,
        Body=b'trigger content', # 替换为你的触发文件实际内容
        IfNoneMatch='*' # 核心原子判断条件：对象已存在则写入失败
    )
    # 仅此处执行成功代表是首次创建触发，不会出现重复写入
except ClientError as e:
    if e.response['Error']['Code'] == 'PreconditionFailed':
        # 对象已存在，直接跳过即可
        pass
    else:
        # 其他异常正常抛出处理
        raise

方案2：Lambda侧增加幂等处理逻辑 #

如果上游的多次写入是业务必需的、无法修改写入逻辑，可以在Lambda侧做幂等控制：

• 用DynamoDB存储已处理过的对象Key记录，Lambda被触发后先查询DynamoDB，若对应Key已存在处理记录则直接跳过，没有记录则执行业务逻辑，处理完成后将Key写入DynamoDB，写入时也需要加条件判断避免并发重复处理。
• 也可以通过S3对象的版本ID、ETag做判断，记录首次写入的版本标识，后续同Key其他版本的触发事件直接跳过。

方案3：增加事件中间层做去重 #

将S3事件先投递到SQS FIFO队列，配置消息去重ID为S3对象的Key，利用SQS FIFO队列的原生去重能力，实现同Key的事件仅被消费一次，之后再由Lambda消费SQS队列执行业务逻辑。

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