如何在Google Cloud Function V2中实现单进程独占执行逻辑？

一、Cloud Function V2 的内存共享规则 #

• 每个Cloud Function V2实例都是完全独立的隔离环境，实例之间内存完全不共享。
• 函数扩容新增实例时，新实例会拥有独立的内存空间，和原有实例没有任何内存层面的交互。
• 单个实例内部可以处理多个并发请求（默认开启并发执行），这些请求共享该实例的内存空间。

二、node-cache 能不能用？ #

可以用，但它的作用范围仅限单个实例内部：

• 同一实例内的多个并发请求，可以通过node-cache共享状态，实现实例内的互斥逻辑。
• 但跨实例的请求完全感知不到node-cache的状态，所以解决不了多实例场景下generateSomething()的互斥问题。

三、低成本跨实例互斥方案 #

如果要确保所有实例中只有单个进程执行generateSomething()，可以用这些比Memorystore成本低的方案：

1. Cloud Firestore 分布式锁 #

利用Firestore的原子操作特性实现锁：

• 尝试创建一个特定ID的锁文档，用set({ ... }, { merge: false })参数，确保只有第一个请求能成功创建文档。
• 成功拿到锁的请求执行generateSomething()，完成后删除锁文档。
• 其他请求轮询检查锁文档是否存在，直到锁被释放再继续执行后续步骤。
• 好处：按读写操作量计费，不用24小时占用资源，成本远低于Memorystore。

2. Cloud Storage 对象锁 #

用Cloud Storage的条件写入特性做锁：

• 尝试创建一个特定名称的空对象，带上ifGenerationMatch=0的条件（只有对象不存在时才会创建成功）。
• 成功创建对象的请求执行generateSomething()，完成后删除这个对象。
• 其他请求定期检查该对象是否存在，直到对象被删除再继续。
• 好处：操作成本极低，特别适合你这种仅需使用3-4小时的场景。

3. 幂等逻辑优化（业务允许的话） #

如果generateSomething()是幂等操作（重复执行不会产生副作用，结果一致），可以不用锁：

• 每个请求都尝试执行generateSomething()，但直接把结果写入最终存储（比如Cloud Storage、Firestore）。
• 后续步骤先检查最终存储里是否已有生成好的资源，有就跳过生成步骤。
• 这种方式依赖存储的原子读取特性，完全不用额外锁服务，成本最低。

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