选择订阅类型

本文档简要介绍了不同类型的订阅在 Pub/Sub 中的工作原理。

订阅概览

如需接收发布到某个主题的消息,您必须创建对该主题的订阅。只有订阅创建后发布到该主题的消息才可供订阅者客户端使用。不过,您也可以启用主题保留,以允许附加到主题的订阅回溯并重放以前发布的消息。订阅者客户端接收并处理发布到该主题的消息。一个主题可以有多个订阅,但给定订阅属于单个主题。

订阅工作流

  1. 向订阅者发送消息后,订阅者必须确认消息。

  2. 如果消息被发送进行传递并且订阅者尚未确认消息,则该消息称为未完成。

  3. Pub/Sub 反复尝试传送任何尚未确认的消息。但是,Pub/Sub 会尝试不向同一订阅的任何其他订阅者传送未完成的消息。

  4. 订阅者可配置一段限定的时间(称为 ackDeadline),用于确认未完成的消息。该期限过后,该消息不再被视为未完成,并且 Pub/Sub 会尝试重新传送该消息。

订阅类型

创建订阅时,您必须指定消息传送类型。Pub/Sub 提供三种类型的消息传送,分别对应于以下三种类型的订阅。本文档的后续部分简要介绍了每种类型的订阅。

  • 拉取订阅
  • 推送订阅
  • BigQuery 订阅

您可以随时更新订阅类型。

拉取订阅

对于拉取订阅,订阅者客户端会向 Pub/Sub 服务器发起请求来检索消息。订阅者客户端使用 REST Pull APIRPC PullRequest APIREST StreamingPullRequest APIRPC StreamingPullRequest API。大多数订阅者客户端不会直接发出这些请求。相反,客户端依赖于 Google Cloud 提供的高级别客户端库,该库在内部执行流式拉取请求并以异步方式传递消息。对于需要更好地控制消息拉取方式的订阅者客户端,Pub/Sub 会使用低级别的自动生成的 gRPC 库。此库会直接发出拉取或流式拉取请求。这些请求可以是同步请求,也可以是异步请求。

以下两张图片显示了订阅者客户端与拉取订阅之间的工作流。

拉取订阅的消息流
图 1.拉取订阅的工作流


StreamingPull 订阅的消息流
图 2.流式拉取订阅的工作流

拉取工作流如下所示,并引用图 1:

  1. 订阅者客户端显式调用拉取方法,该方法会请求传送消息。此请求是如下图所示的 PullRequest。

  2. Pub/Sub 服务器返回零个或多个消息和确认 ID。没有消息或包含错误的响应未必表示没有可接收的消息。此响应是如下图所示的 PullResponse。

  3. 订阅者客户端显式调用已确认的方法。客户端使用返回的确认 ID 来确认消息已处理,无需再次传送。此请求是如下图所示的 AckRequest。

对于单个流式传输拉取请求,订阅者客户端可能会因开放连接而返回多个响应。相反,每个拉取请求仅返回一个响应。

如需详细了解拉取订阅的工作原理和配置示例,请参阅拉取订阅

推送订阅

在推送订阅中,Pub/Sub 服务器向订阅者客户端发起请求以传递消息。

下图显示了订阅者客户端和推送订阅之间的工作流。

推送订阅的消息流
图 3.推送订阅的工作流

以下是引用图 3 的工作流的简要说明:

  1. Pub/Sub 服务器将每条消息作为 HTTPS 请求发送到预配置端点上的订阅者客户端。此请求在图片中显示为 PushRequest。

  2. 端点通过返回 HTTP 成功状态代码来确认消息。如果响应不成功,则表示 Pub/Sub 必须重新发送消息。此响应在图片中显示为 PushResponse。

  3. Pub/Sub 会根据其收到成功响应的速率动态调整推送请求的速率。

如需详细了解推送订阅的工作原理以及配置示例,请参阅推送订阅

BigQuery 订阅

收到消息后,BigQuery 订阅会将消息写入现有 BigQuery 表。您无需配置单独的订阅者客户端。

如果没有 BigQuery 订阅类型,您需要一个拉取或推送订阅以及一个订阅者(例如 Dataflow)来读取消息并将其写入 BigQuery 表。如果消息在将消息存储在 BigQuery 表中之前不需要额外的处理,则无需运行 Dataflow 作业;您可以改用 BigQuery 订阅。不过,对于要求先进行一些数据转换才能将数据存储在 BigQuery 表中的 Pub/Sub 系统,我们仍然推荐使用 Dataflow 流水线。如需了解如何使用 Dataflow 将数据从 Pub/Sub 流式传输到 BigQuery,请参阅从 Pub/Sub 流式传输到 BigQuery

下图显示了 BigQuery 订阅和 BigQuery 之间的工作流。

BigQuery 订阅的消息流
图 4.BigQuery 订阅的工作流

以下是引用图 4 的工作流的简要说明:

  1. Pub/Sub 使用 BigQuery Storage write API 将数据发送到 BigQuery 表。
  2. 这些消息会批量发送到 BigQuery 表。
  3. 写入操作成功完成后,该 API 会返回 OK 响应。
  4. 如果写入操作中存在任何失败情况,系统将否定确认 Pub/Sub 消息本身。然后,系统会重新发送此消息。如果消息失败的次数足够多,并且订阅上配置了死信主题,则该消息会移到死信主题。

如需详细了解 BigQuery 订阅的工作原理,请参阅 BigQuery 订阅

确定订阅类型

下表就如何为您的应用选择合适的交付机制提供了一些指导:

  拉取 推送 BigQuery
用例
  • 大量消息(每秒 GB)。
  • 消息处理的效率和吞吐量至关重要。
  • 设置包含非自签名 SSL 证书的公共 HTTPS 端点的环境。
  • 必须由同一个网络钩子处理的多个主题。
  • App Engine 标准环境和 Cloud Functions 订阅者。
  • 设置 Google Cloud 依赖项(例如凭据和客户端库)的环境不可行。
  • 可扩容到每秒数百万条消息的大量消息。
  • 消息会直接发送到 BigQuery,无需进行任何额外处理。
端点 互联网上具有授权凭据的任何设备都可以调用 Pub/Sub API。 HTTPS 服务器,具有可在公共网页上访问的非自签名证书。接收端点可以与 Pub/Sub 订阅分离,因此来自多个订阅的消息可以发送到单个端点。 BigQuery 表格。
负载平衡 多个订阅者可以对同一个“共享”订阅进行拉取调用。每个订阅者都会接收消息的子集。 推送端点可以是负载均衡器。 Pub/Sub 服务会自动平衡负载。
配置 不需要进行配置。 对于与订阅者属于同一项目的 App Engine 应用,无需进行任何配置。
Google Cloud 控制台中不需要验证推送端点。端点必须使用 DNS 名称进行访问,并已安装 SSL 证书。
主题订阅必须有 BigQuery 表。
流控制 订阅者客户端控制传送速率。订阅者可以动态修改确认时限,从而允许将消息处理设为任意时长。 Pub/Sub 服务器自动实施流控制。无需在客户端处理消息流。但是,通过传回 HTTP 错误可以指示客户端无法处理当前消息加载。 Pub/Sub 服务器自动实现流控制,以优化向 BigQuery 写入消息的操作。
效率和吞吐量 通过批量传送和确认以及大规模并行使用,在低 CPU 和带宽下实现高吞吐量。如果使用积极的轮询来最大限度地缩短消息传送时间,可能效率低下。 每个请求传送一条消息,并限制未完成消息的最大数量。 可伸缩性由 Pub/Sub 服务器动态处理。

默认订阅属性

默认情况下,Pub/Sub 提供至少一次传送,但不保证适用于所有订阅类型。或者,如果消息具有相同的排序键并位于同一区域,则可以启用消息排序。设置消息排序属性后,Pub/Sub 服务会按照相同的排序键以及 Pub/Sub 服务接收消息的顺序传送消息。

Pub/Sub 还支持在预览模式下使用正好一次传送

通常,Pub/Sub 会按照消息的发布顺序传送每条消息。但是,消息有时可能会不按顺序或多次传送。即使针对消息的确认请求成功返回,Pub/Sub 也可能会重新传送消息。这种重新传送可能是由服务器端重启或客户端问题等问题导致的。因此,尽管极少数情况,我们也可以随时重新提交邮件。 为了适应多次传送,订阅者需要在处理消息时遵循幂等原则

订阅到期

默认情况下,订阅会在订阅者处于不活跃状态 31 天后到期,或者如果订阅没有更新,订阅会过期。订阅者活动的示例包括打开连接、主动拉取或成功推送。如果 Pub/Sub 检测到订阅者活动或订阅属性更新,则订阅删除时钟会重启。使用订阅到期政策,您可以配置不活动时长,或者使订阅成为永久性订阅,而无论其活动情况如何。您也可以手动删除订阅。

虽然您可以创建名称与已删除订阅相同的新订阅,但新订阅与旧订阅没有任何关系。即使已删除的订阅包含许多未确认的消息,使用相同名称创建的新订阅在创建时也不会有积压(即没有消息等待传送)。

如需详细了解如何使用订阅,请参阅创建和使用订阅

后续步骤