如何对Google Cloud Storage新上传对象执行恰好一次处理？

该方案无需引入额外的数据库、调度服务等组件，完全复用GCS和Pub/Sub的原生能力，即可实现严格的单文件单次处理，支持无限并发，无单点故障风险。
具体实现步骤如下：

• 第一步保持原有逻辑，为GCS存储桶配置OBJECT_FINALIZE事件触发Pub/Sub消息，消息体需携带文件所属存储桶名、对象名、对象唯一generation号（GCS为每个对象版本分配的全局唯一标识，可避免同名文件覆盖场景的误判）。
• 第二步Python worker收到消息后按以下逻辑执行：
  1. 调用GCS API读取目标对象的自定义元数据，检查是否存在x-goog-meta-processed标记且值为true，如果存在直接ACK消息，结束当前处理流程。
  2. 如果不存在上述标记，调用GCS API尝试为对象追加x-goog-meta-processed: true的自定义元数据，调用时必须携带ifGenerationMatch参数，值为消息中携带的对象generation号：该参数是乐观锁的核心，仅当GCS中当前对象的版本与消息中的版本一致、且对象元数据未被其他进程修改时，更新请求才会成功。
  3. 如果元数据更新失败，说明已有其他worker抢到该文件的处理权，直接ACK消息即可。
  4. 如果元数据更新成功，说明当前worker拿到了该文件的唯一处理权限，开始执行业务逻辑处理文件。
  5. 文件处理完成后ACK消息即可。如果处理过程中worker崩溃，Pub/Sub会在消息超时后重新投递，后续收到消息的worker检查到已处理标记会直接跳过，不会出现重复处理。

该方案的优势非常贴合你的需求：

• 无额外运维成本：不需要单独部署数据库、调度中心等服务，所有能力均为GCP服务原生提供，额外产生的元数据操作成本几乎可以忽略。
• 无并发瓶颈、无单点问题：worker可以任意横向扩展，锁逻辑由GCS分布式实现，吞吐量上限极高。
• 覆盖极端场景：通过generation号的校验，即使出现同名文件覆盖上传的情况，新文件的处理流程也不会被旧的已处理标记拦截。

如果你的文件处理逻辑本身支持幂等（即同一文件重复执行多次不会产生脏数据、重复输出等问题），可以采用更简单的实现：

• 为Pub/Sub订阅设置最大重试次数（比如3次），并配置死信队列接收超过重试次数的消息。
• worker收到消息后直接执行处理逻辑，处理成功则ACK，处理失败则NACK触发重试。
• 定期处理死信队列中的异常消息即可，该方案实现成本最低，绝大多数场景下的重复处理概率可以忽略。

补充说明：你之前考虑的PostgreSQL分布式锁方案也完全可行，只是对于中小规模的场景而言，上述GCS原生方案的运维和成本优势更明显；Eventarc底层本质是封装了Pub/Sub，投递规则和Pub/Sub一致为至少一次投递，同样可以搭配上述乐观锁方案使用，无需纠结Eventarc的恰好一次投递承诺。

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