对于从 PubSub 触发的 Cloud Run，何时为请求消息发送 ACK 合适？

Question

我正在构建一个在Cloud Run 上运行的服务，该服务由PubSub 到EventArc 触发。 'PubSub' 保证至少交付一次，并且会在每个acknowledgement 截止日期重试。此截止日期在队列订阅详细信息中设置。

我们可以在服务接收到 pub-sub 请求（在服务中作为 POST 请求接收）时在两个时间点发回确认。

1. 在收到请求后立即开始请求。然后，该服务将继续按照自己的节奏处理请求。但是，article 指出

当运行在 Cloud Run 上的应用处理完请求后，容器实例对 CPU 的访问将被禁用或受到严重限制。因此，您不应启动在请求处理程序范围之外运行的后台线程或例程。

所以一开始就发送响应可能不是一种选择

1. 服务处理完请求后。所以这意味着，根据服务将做什么，我们不能总是预测处理请求需要多长时间。因此，我们无法正确设置确认截止日期，从而导致 PubSub 重试和重复请求。

那么这里的最佳做法是什么？有没有更好的方法来处理这个问题？

Answer 1

由于您担心自己可能无法设置正确的“确认截止日期”，您可以在代码中使用modify_ack_deadline()，如果流程仍在运行，您可以动态延长截止日期。示例代码实现可以参考这个document。

请注意maximum acknowledgement deadline is 600 seconds。只需确保您在云运行中的处理不超过上述限制即可。

Answer 2

最佳做法通常是在处理完成后确认消息。除了您链接的 Cloud Run 限制之外，请考虑如果端点在收到消息后立即确认，然后在处理它时发生错误，您的应用程序可能会丢失该消息。

为了尽量减少重复，您可以将确认截止日期设置为处理时间的上限。 （如果您的端点最终以比这更快的速度处理消息，则确认截止日期不会限制传入消息的速率。）如果 600 秒的截止日期还不够，您可以考虑将消息写入某个持久存储然后确认它。然后，单独的工作人员可以异步处理来自持久存储的消息。

Answer 3

Acknowledgements 不适用于 Cloud Run，因为 Acks 用于“拉取订阅”，其中一个进程不断拉取 Cloud PubSub API。

要将事件从 PubSub 获取到 Cloud Run，您可以使用“推送订阅”，其中 PubSub 向 Cloud Run 发出 HTTP 请求，并等待它完成。

在此推送场景中，PubSub 已经知道它向您发出了请求（您收到了事件），因此它不需要确认收到消息。但是，如果您的请求发送了错误的响应代码（例如 http 500），PubSub 将发出另一个请求以重试（这可以在推送订阅本身上进行配置）。