我有一个可以运行长达 60 分钟的云运行服务。pubsub 是执行云运行服务的触发点。 重试策略的 pubsub 配置设置为 max (600s)。
现在，当从 pubsub 发布消息时，cloud run 开始执行，因为完整的执行大约需要 60 分钟才能完成，但是 600 秒后的 pubsub 消息开始再次重试，因为它没有收到来自 cloud run 的任何确认，并且再次导致云运行服务一次又一次地执行。
这里如何处理pubsub重试，让cloud run不会因为重试而反复执行。
【问题讨论】：
标签： google-cloud-platform google-cloud-pubsub google-cloud-run
我正在考虑使用 Cloud Tasks 或 Cloud Workflows 作为长期运行的 Cloud Run 的代理。不幸的是，这两项服务的最大超时时间为 1800 秒（30 分钟）。顺便说一下，Cloud Workflows 即将推出的回调功能将有 12 小时超时。同时，我将创建一个代理作为由 PubSub 消息触发的 Cloud Function，该代理将立即得到确认，并且该函数将与 PubSub 消息异步调用您的 Cloud Run 并立即返回。
【讨论】：
对于推送订阅，例如您在 Cloud Run 服务中使用的订阅，消息的最大确认截止日期确实是 600 秒。如果使用 pull，可以致电ModifyAckDeadline 延长消息的截止日期。事实上，Cloud Pub/Sub do this automatically 的客户端库最多可使用配置的时间（默认为 60m）。
如果使用推送订阅，则无法延长截止日期。因此，您的选择是：
切换到请求订阅。你可以potentially do this via Cloud Run，虽然它不是最合适的。更有可能的是，您希望在无需任何触发器的情况下保持其运行的环境中启动作业，例如 GKE。如果切换到 pull，则可以延长 ack 截止日期，但请注意，即使 ack 截止日期尚未过期或消息已被确认，仍然可能出现重复。它们应该很少见，但您仍然必须考虑到它。
当您收到消息时，将其保存在某个地方，无论是在磁盘上还是在数据库中，然后在保存后确认该消息。一个小时后，一旦你真正完成了对消息的处理，你就可以将它从这个持久存储中删除。当然，您可以只保留消息而不是通过 Pub/Sub 发布它，并依靠持久层的通知机制来了解新消息。例如，如果你写信给 GCS，你可以使用Cloud Storage notifications via Pub/Sub。在这种情况下，您可能希望定期从存储中读取一些消息，以查看是否有任何消息在一段时间内未处理，如果有，请重新处理它们。例如，如果您在消息中写下开始处理的时间，并且从那时起已经过去了超过一定时间并且消息仍然存在，则您可以重新开始处理。
【讨论】：