GCP 数据流的推送与拉取

Posted 2023-02-16

【中文标题】GCP 数据流的推送与拉取

【英文标题】：Push vs Pull for GCP Dataflow

【发布时间】：2020-11-09 19:46:59

【问题描述】：

我想知道应该在 GCP pubsub 中创建哪种类型的订阅，以便处理来自 pubsub 主题的高频数据。 我将以每秒 100 多条消息的速度在数据流中摄取数据。 拉取或推送订阅真的很重要，以及它将如何影响速度等等。

【问题讨论】：

欢迎来到 *** =) 请检查如何提出一个好问题：***.com/help/how-to-ask。多花几分钟让你的问题清晰具体，将极大地改善某人回答问题的变化，并且答案很有帮助。

【参考方案1】：

如果您通过 Dataflow 使用 PubSub 订阅，则只有 Pull 订阅可用

要么创建一个，然后在数据流管道的参数中提供它 或者您仅在数据流管道中指定主题，Dataflow 将自行创建拉取订阅。

如果这两种情况，Dataflow 将以流模式处理消息

区别

如果您自己创建订阅，所有消息将被存储和保留（默认最多 7 天），并在数据流管道启动时使用。

如果您让 Dataflow 创建订阅，则只有在订阅创建之后到达的消息才会被数据流管道使用。如果您不想丢失消息，则不推荐使用此解决方案。如果你不关心旧消息，这是一个不错的选择。

高频

那么，每秒100条消息绝对不是高频。 1 个 pubsub 主题每秒最多可以摄取 1 000 000 条消息。别担心！

推VS拉

型号不同。

使用推送订阅，您必须指定一个使用该消息的 HTTP 端点（在 GCP 或其他地方）。这是一个 webhook 模式。如果平台端点随流量自动扩展（例如 Cloud Run、Cloud Functions），则消息速率可能会非常高！！ HTTP 返回码代表消息确认。 使用拉订阅，客户端需要打开订阅连接，然后拉消息。客户端需要明确地确认消息。可以同时连接多个客户端。使用客户端库，消息通过 gRPC 协议使用，接收和使用消息的效率更高（在网络带宽方面）

安全角度

使用推送，如果端点需要身份验证，则它是要在 HTTP 端点上进行身份验证的 PubSub

使用 pull 时，需要在 PubSub 订阅上对客户端进行身份验证。