使用长时间运行的任务推送订阅

Question

我的任务可以在大约 3 分钟内完成。 Cloud Run 提供 600 秒的最大超时时间，因此这不是问题。我们决定使用 Cloud Run + Pub/Sub 进行推送订阅。

Workers（由于第 3 方库速率限制，我有 4 个 Cloud Run 实例）有一个端点，其中 pub/sub 可以通过推送订阅发送消息。然而，当许多消息突然发布时，我们就会看到问题。想象一下这个场景：

• 突然发布了100条消息。
• 4个worker已经开始运行，有4条消息。

其余消息（96 条消息）收到 429/500，因为我们没有更多工作人员来处理这些消息（“由于没有可用实例，请求被中止。其他故障排除文档可在以下位置找到：https ://cloud.google.com/run/docs/troubleshooting#abort-request"）。根据重试最小/最大值，它们将被推送给工作人员。我们假设

• 重试时间为4分钟。
• 每条消息在从主题中删除之前可以重试 5 次。

4 分钟后，92 条消息出现第二次重试错误。根据您在推送订阅设置下设置的重试次数，消息最终将超出已发布的主题。在我描述的场景中，我们需要 75 分钟来处理所有消息；但是，20分钟内，该主题中不会有任何消息需要处理。

重试前的最大等待时间为 10 分钟，最大投递尝试次数为 100。在我的场景中，如果大小超过 300，则无法处理该主题的消息。

所以，我需要的是流量控制——只有请求订阅才有流量控制（更多这里）。推送订阅具有push-backoff，这对于需要超过 60 秒才能完成的任务没有用。

我在这里有点困惑。

• 我想使用 Cloud Run 来实现可扩展性 + 成本效率。
• 我不想进行疯狂的实现，例如拥有两个订阅 - 一个是用于唤醒云运行实例的推送订阅，第二个是在云运行内部，我可以在其中控制负载。出于多种原因，这不是一个好的解决方案，但它也没有什么用处，因为总超时只有 10 分钟（在我的例子中，我只能处理 3 条消息）。我相信如果我切换到云任务，这个解决方案会更加富有成效 - 至少，我可以处理更多的消息。

另一种选择是通过了解消息负载，使用我自己的脚本启动更多工作人员，但我觉得我要与火箭筒打架。

针对这种场景的策略是什么？我认为这对于云运行+发布/订阅来说应该是一个相当简单的任务，但我有点失望。我在这里错过了什么吗？

Answer 1

你是对的，你不能用 PubSub Push 来做到这一点。 您可以通过请求订阅来做到这一点，因为您对此有更多的控制权。然而，它改变了语义。

我会考虑使用 Cloud Tasks (https://cloud.google.com/tasks)。云任务的工作方式与 PubSub Push 类似（即，它调用 HTTP 端点），并让您可以更好地控制如何安排任务。

您可以设置队列可以调度的最大并发任务速率和数量。

https://cloud.google.com/tasks/docs/configuring-queues#rate

它并不完全是直接替代品，但接近于替代品。