来自发布/订阅主题的速率限制 GCP 云函数触发器答案

【问题标题】：Rate limit GCP Cloud Function triggers from pub/sub topic来自发布/订阅主题的速率限制 GCP 云函数触发器
【发布时间】：2021-10-21 02:14:15
【问题描述】：

我有一个从 Pub/Sub 主题触发的云函数。

我想限制我的 Cloud Functions 的速率，因此我将最大实例数设置为 5。在我的情况下，生成的消息将比 Cloud Functions 多得多（并且我想限制正在运行的 Cloud Functions 的数量）。

我希望这个过程表现得像 Kafka/queue——主题消息会被累积，云函数会慢慢消费消息，直到主题为空。

但似乎所有没有触发云功能（ack）的消息，只是简单地发送了一个 UNACK - 并留下了。我的订阅详情：

确认截止日期最大值对我来说太低（由于速率限制，云函数可能需要几个小时才能收到消息）。

我可以在 Pub/Sub 中进行哪些更改以满足我的需求？或者我需要添加一个队列？（Pub/Sub 发送到任务队列，云函数使用任务队列？）。

顺便说一句，发布/订阅数据实际上是 GCS 事件。如果这是 AWS，我只需将 S3 文件创建的事件发送到 SQS，并在队列的另一端使用 Lambda。

任何帮助将不胜感激。

【问题讨论】：

【解决方案1】：

您无法与 kafka 进行比较，因为您的 kafka 消费者在方便时拉取消息，而 Cloud Function(CF) 创建一个推送订阅，将消息推送到您的 CF。所以一些替代方案：

创建一个由云调度程序触发的 HTTP CF，它将从您的 PULL 订阅中提取消息。未确认消息的最长保留时间为 7 天（希望够用）
使用您增加最大并发（最大并发请求）的云，并具有适当的 CPU 和 RAM 大小。当然，您可以控制云运行实例的最大数量（不同于最大并发数）。并使用 PUSH 订阅推送到云端运行。但在这里，您也将受到 10 分钟确认截止日期的限制。

【讨论】：

【解决方案2】：

理想的解决方案是更改重试策略。使用“在指数退避延迟后重试”时，Pub/Sub 即使在最大指数延迟（600 秒）之后也会继续重试。这样，您可以在 Pub/Sub 中拥有大量消息，并使用一些 Cloud Functions 慢慢处理它们 - 这符合我们对速率限制的需求。

基本上，一切都一样，只是这个配置发生了变化，结果是：

这正是我想要的:)

【讨论】：