Cloud Run API冷启动时重复请求的问题排查与解决需求

问题详情 #

• 基于Cloud Run搭建的API后端处理HTTP POST请求时，系统闲置进入冷启动状态后，新请求会被重复处理，引发重复操作（日志显示同一message_id（1935379776）的请求被处理两次，其中Google Search API仅调用1次，但SMS API被调用2次）

已尝试的无效方案 #

• 收到请求后立即返回响应，后台异步处理请求，问题未解决
• 通过临时集合存储message_id做去重，识别重复请求并忽略，该机制未生效

可能原因分析 #

1. Cloud Run冷启动时，负载均衡因实例启动超时会自动重试发送请求，导致同一请求被多个实例或同一实例多次处理
2. 临时集合的去重逻辑存在并发窗口问题：两次请求几乎同时到达，去重判断还未完成就进入处理流程
3. 后台异步任务未与实例生命周期正确绑定，实例启动过程中任务被重复调度

可行解决方案 #

1. 避免冷启动（适合有稳定流量场景） #

设置Cloud Run的--min-instances参数为至少1，保留常驻实例，彻底避免冷启动带来的重试问题。注意该配置会增加一定成本，需根据流量情况评估。

2. 实现可靠的幂等性处理 #

• 替换临时集合，改用持久化存储（如Cloud Firestore、Cloud Memorystore）存储已处理的message_id，并设置合理的过期时间（比如1小时，避免存储冗余）
• 请求处理流程调整：
  1. 接收请求后，首先检查持久化存储中是否存在当前message_id
  2. 若存在，直接返回200 OK响应，不执行后续业务逻辑
  3. 若不存在，通过事务将message_id写入存储，再执行搜索、调用SMS API等业务操作
     （使用事务可以避免并发场景下的重复写入，确保去重逻辑可靠）

3. 调整实例启动与请求超时配置 #

• 延长Cloud Run实例的启动超时时间（通过--timeout参数），给实例足够的启动时间，减少负载均衡的重试触发
• 确保HTTP请求的响应在幂等性检查完成后再返回，避免先返回响应后，后台处理被重复触发

4. 检查负载均衡重试策略 #

确认Cloud Run前端的负载均衡是否对POST请求开启了不必要的重试，对于非幂等的POST请求，建议关闭重试配置；若业务必须依赖重试，则务必保证所有业务操作都是幂等的

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