选择订阅类型

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

订阅概览

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

订阅工作流程

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

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

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

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

订阅类型

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

  • 拉取订阅
  • 推送订阅

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

拉取订阅

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

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

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


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

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

  1. 订阅者客户端显式调用拉取方法,该方法会请求消息以进行传送。此请求为拉取请求,如图片所示。

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

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

流式拉取和拉取工作流之间的主要区别在于,对于单个流式拉取请求,订阅者客户端可以返回多个响应,因为存在打开的连接。相反,每个拉取请求仅返回一个响应。

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

推送订阅

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

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

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

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

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

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

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

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

选择订阅类型

下表提供了一些指导,帮助您为应用选择适当的传送机制:

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

默认订阅属性

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

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

一般情况下,Pub/Sub 会按照消息的发布顺序传送每条消息。不过,消息有时可能会不按顺序传送或多次传送。若要接受多次传送,订阅者需要在处理消息时遵循幂等原则。

订阅到期

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

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

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

后续步骤