Pub/Sub 服务概览

Pub/Sub 是一种发布/订阅 (Pub/Sub) 服务，即消息的发送者与消息的接收者分离的消息传递服务。Pub/Sub 服务包含几个关键概念，以下图表将帮助您了解这些概念。

图示：Pub/Sub 服务的不同组件以及它们如何彼此关联。
图 1 两个发布者客户端向一个共同的 Pub/Sub 主题发送两条不同的消息。

Pub/Sub 服务包含以下组件：

  • 发布者（也称为生产者）：创建消息并将其发送（发布）到指定主题上的消息传递服务。

  • 消息：通过服务移动的数据。

  • 主题：代表消息源的命名实体。

  • 架构：一种命名实体，用于控制 Pub/Sub 消息的数据格式。

  • 订阅：代表有兴趣接收特定主题的消息的命名实体。

  • 订阅者（也称为使用者）：接收指定订阅的消息。

以下流程介绍了 Pub/Sub 服务的工作流：

  1. 两个发布者应用（发布者 1 和发布者 2）向单个 Pub/Sub 主题发送消息。发布者 1 发送消息 A，发布者 2 发送消息 B。

  2. 主题本身附加到两个订阅。这些订阅分别是订阅 1 和订阅 2。

  3. 主题还附加到架构。

  4. 每个订阅都会收到主题中 A 和 B 消息的副本。

  5. 订阅 1 连接到两个订阅者应用，即订阅者 1 和订阅者 2。这两个订阅者应用会接收主题中的一部分消息。在此示例中，订阅者 1 接收来自主题的消息 B，而订阅者 2 接收来自主题的消息 A。

  6. 订阅 2 仅与名为订阅者 3 的单个订阅者应用相关联。因此，订阅者 3 会接收来自该主题的所有消息。

消息的生命周期

假设单个发布者客户端已连接到某个主题。 相应主题附加了单个订阅。单个订阅者已连接到订阅。

显示消息如何在 Pub/Sub 中流动的图。
图 2 消息通过 Pub/Sub 从发布者客户端流向订阅者客户端。

以下步骤介绍了消息在 Pub/Sub 中的传送方式：

  1. 发布者应用将消息发送到 Pub/Sub 主题。

  2. 消息写入到存储空间。

  3. 在将消息写入存储空间的同时，Pub/Sub 会将消息传送给主题的所有附加订阅。

    在此示例中，它是一项订阅。

  4. 订阅将消息发送到关联的订阅者应用。

  5. 订阅者向 Pub/Sub 发送确认，表明它们已处理该消息。

    在每个订阅的至少一个订阅者确认消息之后，Pub/Sub 将从存储空间中删除该消息。

Pub/Sub 中消息的状态

如果向某个订阅者发送的消息未完成，Pub/Sub 会尝试不将其传送给同一订阅的任何其他订阅者。订阅者可配置一段限定的时间（称为 ackDeadline），用于确认未完成的消息。该时限过后，该消息不再被视为未完成，并且可以再次传送。

Pub/Sub 服务中的消息可以处于以下三种状态：

  • 已确认的消息（已确认）。订阅者应用处理从主题发送到订阅的消息后，会向 Pub/Sub 发送确认。如果某个主题上的所有订阅都已确认消息，系统将从发布消息源和存储空间中异步删除该消息。

  • 未确认的消息（未确认）。如果 Pub/Sub 在确认时限内未收到确认，则可能会多次传送消息。例如，订阅方可能会在截止时间过期后发送确认，或者确认可能会因暂时性网络问题而丢失。未确认的消息会继续传送，直到自消息发布以来消息保留时长到期为止。此时，消息过期。

  • 被否定确认的消息 (nacked)。订阅者否定确认消息会导致 Pub/Sub 根据默认重试设置立即重新传送消息，这些设置可以修改。当订阅者否定确认无效消息或无法处理消息时，订阅者有助于确保这些消息不会丢失，并且能够成功处理。您可以将 modifyAckDeadline 的值设为 0，以否定确认消息。

选择 Pub/Sub 发布和订阅模式

当有多个 Pub/Sub 发布者和订阅者客户端时，您还必须选择要设置的发布和订阅架构类型。

显示不同发布和订阅模式的图。
图 3 发布者-订阅者关系可以为多对一（扇入）、多对多（负载平衡）和一对多（扇出）。

受支持的部分 Pub/Sub 发布订阅模式包括：

  • 扇入（多对一）。在此示例中，多个发布者应用将消息发布到单个主题。此单个主题附加到单个订阅。订阅随后会连接到单个订阅者应用，该应用会接收主题中的所有已发布消息。

  • 负载均衡（多对多）。在此示例中，一个或多个发布者应用将消息发布到单个主题。此单个主题附加到单个订阅，而该订阅又连接到多个订阅者应用。每个订阅者应用都会收到一部分已发布的消息，并且没有两个订阅者应用会收到相同的一部分消息。在此负载均衡示例中，您可以使用多个订阅者来大规模处理消息。如果需要支持更多消息，您可以添加更多订阅者来接收来自同一订阅的消息。

  • 扇出（一对多）。在此示例中，单个或多个发布者应用将消息发布到单个主题。此单个主题附加到多个订阅。每个订阅都与单个订阅者应用相关联。每个订阅者应用都会从主题中获得相同的已发布消息集。如果主题有多个订阅，则每条消息都必须发送给代表每个订阅接收消息的订阅者。如果您需要对同一组消息执行不同的数据操作，扇出是一个不错的选择。您还可以为每个订阅附加多个订阅者，并为每个订阅者获取经过负载平衡的消息子集。

选择 Pub/Sub 配置选项

您可以使用以下任一选项配置 Pub/Sub 环境：

  • Google Cloud 控制台
  • Google Cloud CLI
  • Cloud 客户端库（高级客户端库）
  • REST 和 RPC API（低层级客户端库）

您选择的 Pub/Sub 配置选项取决于您的使用情形。

如果您是 Google Cloud 控制台的新用户，并且想要测试 Pub/Sub，请使用控制台或 gcloud CLI。

如果需要高吞吐量和低延迟，同时尽可能减少运营开销和处理费用，建议使用高级客户端库。默认情况下，高级别客户端库使用 StreamingPull API。高级客户端库包含预建的函数和类，可处理身份验证、吞吐量和延迟时间优化、消息格式设置以及其他功能的底层 API 调用。

低级客户端库是自动生成的 gRPC 库，当您直接使用服务 API 时，它会发挥作用。

以下是使用客户端库的一些最佳实践：

  • 选择合适的客户端库语言。Pub/Sub 客户端库的性能因语言而异。例如，Java 客户端库在纵向伸缩方面比 Python 客户端库更有效，并且可以处理更高的吞吐量。就处理发布或订阅负载所需的计算资源而言，Java、C++ 和 Go 是更高效的语言。

  • 使用最新版本的客户端库。Pub/Sub 客户端库会不断更新，以加入新功能和修复 bug。确保您使用的是适用于相应语言的最新版客户端库。

  • 重复使用发布商客户端。发布消息时，重复使用同一发布者客户端比为每个发布请求创建新的发布者客户端更高效。这是因为在创建新的发布者客户端后，第一个发布请求需要一些时间来建立授权连接。在某些没有明确发布者客户端的语言（例如 Node）中，请重复使用您调用发布方法的对象。例如，在 Node 中，保存并重复使用主题对象。

如何设置 Pub/Sub

以下是配置 Pub/Sub 的顶级步骤：

  1. 创建或选择一个 Google Cloud 可以设置 Pub/Sub 的项目。

  2. 启用 Pub/Sub API。

  3. 获取运行 Pub/Sub 所需的角色和权限。

  4. 创建主题。

  5. 如果消息结构至关重要，请为消息定义架构。

  6. 将架构附加到主题。

  7. 配置可向主题发布消息的发布者客户端。

  8. 如果需要，请配置高级发布选项，例如流量控制、批量消息传递和并发控制。

  9. 根据您希望接收消息的方式选择订阅类型。

  10. 为所选主题创建订阅。

  11. 配置可接收订阅消息的订阅方客户端。

  12. 如果需要，请配置高级消息传递选项，例如“仅一次”传递、租约管理、按序传递和流量控制。

  13. 开始从发布者客户端向主题发布消息。

  14. 同时，设置订阅方客户端以接收和处理这些消息。

主题、订阅、架构或快照命名指南

Pub/Sub 资源名称唯一标识 Pub/Sub 资源，例如主题、订阅、架构或快照。资源名称必须符合以下格式：

projects/project-identifier/collection/ID

  • project-identifier：必须是项目 ID 或项目编号，可在 Google Cloud 控制台中找到。例如，my-cool-project 是项目 ID。 123456789123 是项目编号。

  • collection：必须是 topics、subscriptions、schemas 或 snapshots 中的一个。

  • ID：必须符合以下准则：

    • 不以字符串 goog 开头
    • 以字母开头
    • 包含 3 到 255 个字符
    • 仅包含以下字符：字母 [A-Za-z]、数字 [0-9]、短划线 -、下划线 _、英文句点 .、波形符 ~、加号 + 和百分号 %

    您可以在资源名称中使用上述列表中的特殊字符，而无需进行网址编码。不过，在网址中使用任何其他特殊字符时，您必须确保对这些字符正确进行编码或解码。例如，mi-tópico 是无效的 ID。不过，mi-t%C3%B3pico 是有效的。在进行 REST 调用时，此格式非常重要。

后续步骤