订阅者概览

本文档概括介绍 Cloud Pub/Sub 中订阅的工作原理。如需详细了解拉取和推送传送订阅,请参阅拉取订阅者指南推送订阅者指南

要接收发布到主题的消息,您必须创建对该主题的订阅。订阅者应用只能获取创建订阅后发布到该主题的消息。订阅将主题与负责接收和处理发布到该主题的消息的订阅者应用关联起来。一个主题可以有多个订阅,但给定订阅属于单个主题。

要了解如何创建和更新订阅,请参阅管理主题和订阅

至少传送一次

Cloud Pub/Sub 会为每个订阅将发布的每条消息至少传送一次。这种“至少一次”行为有一些例外情况:

  • 默认情况下,在最长保留时间(7 天)内无法传送的消息将被删除,并且不能再访问。这种情况通常会在订阅者无法应对消息流时发生。请注意,您可以配置消息保留持续时间(范围为 10 分钟到 7 天)。请参阅重放和舍弃消息,详细了解消息保留设置。
  • 在给定订阅创建之前发布的消息通常不会针对此订阅进行传送。因此,如果某主题没有订阅,则发布到该主题的消息将不会传送给任何订阅者。

消息发送至订阅者后,订阅者应确认消息。在消息发送出去待传送之后到订阅者确认消息之前的这段时间,消息会被视为未完成。Cloud Pub/Sub 将重复尝试传送任何尚未确认的消息。但是,如果向某个订阅者发送的消息未完成,Cloud Pub/Sub 会尝试不将其传送给同一订阅的任何其他订阅者。订阅者可配置一段限定的时间(称为 ackDeadline),用于确认未完成的消息。该时限过后,该消息不再被视为未完成,Cloud Pub/Sub 将尝试重新传送该消息。

通常,Cloud Pub/Sub 会按照消息发布的顺序将每条消息传送一次,但有时可能并不按顺序传送消息,或者会将消息传送多次。一般来说,如果要实施多次传送,订阅者需要在处理消息时遵循幂等原则。您可以使用 Cloud Dataflow PubsubIO 将 Cloud Pub/Sub 消息流只处理一次。PubsubIO 会根据自定义消息标识符或由 Cloud Pub/Sub 分配的消息标识符来删除重复的消息。您还可以使用服务的标准排序 API 通过 Cloud Dataflow 实现有序处理。或者,为了实现排序,您订阅的主题的发布者可以在消息中包含序列令牌。如需了解详情,请参阅消息排序

拉取或推送传送

订阅可以使用拉取或推送机制来传送消息。您可以随时更改或配置该机制。

拉取订阅

在拉取传送模式下,订阅者应用向 Cloud Pub/Sub 服务器发起请求来检索消息。

  1. 订阅应用明确调用拉取方法,该方法将请求待传送的消息。
  2. Cloud Pub/Sub 服务器返回消息和确认 ID 以进行响应(或者如果队列为空,则返回错误)。
  3. 订阅者明确调用确认方法,使用返回的确认 ID 来确认收到消息。

拉取订阅消息请求流

推送订阅

在推送传送模式下,Cloud Pub/Sub 向订阅者应用发起请求来传送消息。

  1. Cloud Pub/Sub 服务器将每条消息作为 HTTPS 请求发送到预配置端点上的订阅者应用。
  2. 端点通过返回 HTTP 成功状态代码来确认消息。不成功响应表明应重新发送消息。

推送订阅消息请求流

Cloud Pub/Sub 将根据收到成功响应的速率来动态调整推送请求的速率。

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

拉取 推送
  • 大量消息(远超过 1 条/秒)。
  • 消息处理的效率和吞吐量至关重要。
  • 公共 HTTPS 端点,具有非自签名 SSL 证书,无法进行设置。
  • 必须由同一个 Webhook 处理的多个主题。
  • App Engine 标准环境和 Cloud Functions 订阅者。
  • 无法设置 Google Cloud Platform 依赖项(例如凭据和客户端库)的环境。

下表比较了拉取传送和推送传送:

  拉取 推送
端点 互联网上具有授权凭据的任何设备都能调用 Cloud Pub/Sub API。 可以在公共网络上访问的具有非自签名证书的 HTTPS 服务器。接收端点可以与 Cloud Pub/Sub 订阅分离,因而来自多个订阅的消息可以发送到单个端点。
负载平衡 多个订阅者可以对同一个“共享”订阅进行拉取调用。每个订阅者都将收到一部分消息。 推送端点可以充当负载平衡器。
配置 不需要进行配置。 如果 App Engine 应用与订阅者属于同一项目,则不需要进行配置。
对于所有其他端点,需要在 Google Cloud Platform Console 中配置(和验证)推送端点。端点必须支持通过 DNS 名称进行访问,并且安装有 SSL 证书。
流控制 订阅者客户端控制传送速率。订阅者可以动态修改确认时限,从而允许将处理消息所用时间设为任意长度。 Cloud Pub/Sub 服务器自动实施流控制。尽管可以通过传回 HTTP 错误来指示客户端无法处理当前消息负载,但并不需要在客户端上处理消息流。
效率和吞吐量 通过批量传送和确认以及大规模并行处理,在低 CPU 和带宽下实现高吞吐量。如果使用积极的轮询来最大限度缩短消息传送时间,则可能效率低下。 每个请求传送一条消息并限制未完成消息的最大数量。

订阅的生命周期

默认情况下,订阅在 31 天不活动(例如,如果没有活动连接、拉取请求或推送成功)后过期。如果 Cloud Pub/Sub 检测到订阅者活动,则订阅删除时钟会重新启动。使用订阅到期政策(测试版),您可以配置不活动持续时间,或者使订阅成为永久性订阅,而无论其存在时间如何。您也可以手动删除订阅。

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

如需详细了解如何使用订阅,请参阅配置订阅

此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
Cloud Pub/Sub