常见问题解答

一般问题

Pub/Sub 与 Firebase 云消息传递 (FCM) 或已弃用的 Google Cloud Messaging (GCM) 是否相关?

既相关也不相关。这些系统均用于传送消息,但 FCM 用于与最终用户设备之间传送消息,而 Pub/Sub 用于在服务器之间进行通信。FCM 旨在扩容到大量传送端点,但吞吐量(每个通道每秒的消息数)较低。Pub/Sub 对吞吐量没有限制,并采用更通用的 API。

它与 PubSubHubbub 是否相关?

不相关。尽管源 PubSubHubbub 也有 Google 员工的密切参与,但其优势在于 RSS 和内容联合发布方面,而这些通常不是 Pub/Sub 的目标使用场景。除了名称之外,它们几乎没有什么共同之处。

是否可以使用 Pub/Sub 在不同的 App Engine 模块之间进行通信?

可以。您可以使用 Pub/Sub 在 App Engine 应用中的不同模块之间(甚至在同一项目中的不同应用之间)发送和接收消息,而无需任何特殊的 ACL 配置。如需实现低延迟发布,请以全局变量形式初始化发布者客户端,从而缓存该客户端。

是否可以将 Pub/Sub 与 App Engine 以外的平台搭配使用?

可以。您可以将 Pub/Sub 与 Google Compute Engine(甚至是非 Google 平台)上托管的应用搭配使用。只需一个 Google Cloud Console 项目即可开始使用。如需实现低延迟发布,请考虑将发布者客户端设置为全局变量,从而缓存该客户端。

如何关联 App Engine 和 Compute Engine 应用?

使用推送传送可实现从 Compute Engine 到 App Engine 的低延迟消息传递。使用拉取传送可将数据从 App Engine 发送至大量 Compute Engine 订阅者。

如何监控 Pub/Sub 指标?

请参阅这篇文章

Pub/Sub 是否与 Cloud KMS 集成?

是。您可以配置 Pub/Sub 主题,以使用 Cloud KMS 中的密钥保护消息内容。如需了解详情,请参阅使用 CMEK(客户管理的加密密钥)

技术问题

消息是否按顺序传送?

Pub/Sub 不保证按顺序或以 FIFO(先进先出)方式传送消息。系统会尽可能快地传送消息,优先传送较早的消息,但并不保证一定会如此。严格排序与 Pub/Sub 的可用性和可扩缩性保证相矛盾。如需详细了解关于此主题的讨论,请参阅消息排序

我的使用量低于限制,为什么还出现了配额错误?

系统将对与经过身份验证的客户端关联的项目强制实施配额,如配额和限制所述。请确保您正使用的服务帐号或 API_KEY 所关联的项目具有足够的配额。尤其需要注意的是,gcloud 命令行使用共享项目,配额非常有限。

为什么有太多重复的消息?

Pub/Sub 保证消息至少传送一次,这意味着偶尔会出现重复。但是,重复率过高可能表示客户端未在配置的 ack_deadline_seconds 内确认消息,而 Pub/Sub 正在重新尝试传送消息。您可以通过查看监控指标 pubsub.googleapis.com/subscription/pull_ack_message_operation_count(对于拉取订阅)和 pubsub.googleapis.com/subscription/push_request_count(对于推送订阅)了解相应信息。请在 /response_code 中查找增加的 expiredwebhook_timeout 值。这在具有许多较小消息的情况下特别有可能,因为 Pub/Sub 可以在内部批量处理消息,而且部分确认的批量消息将完全重新传送。

另一种可能性是:由于处理某些特定消息的代码路径失败,并且从未进行 Acknowledge 调用,因此订阅者没有确认这些消息;或者推送端点从未响应或者响应但返回错误。

如何检测重复消息?

Pub/Sub 为每条消息分配一个唯一的“message_id”,可用于检测订阅者收到的重复消息。但是,这将不允许您检测对相同数据的多个发布请求所产生的重复项。检测这些重复项将需要发布者提供唯一的消息标识符。如需进一步的讨论,请参阅 Pub/Sub I/O