GCP 数据流的推送与拉取

Ayu*_*loi -1 dataflow google-cloud-platform google-cloud-pubsub apache-beam

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

gui*_*ere 9

如果您通过 Dataflow 使用 PubSub 订阅,则只有拉取订阅可用

  • 要么创建一个,要么在数据流管道的参数中提供它
  • 或者您仅在数据流管道中指定主题,Dataflow 将自行创建请求订阅。

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

区别

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

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

高频

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

推VS拉

型号不一样。

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

安全观点

使用推送,如果端点需要身份验证,则在 HTTP 端点上对 PubSub 进行身份验证

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