Pub/Sub 是一种 发布/订阅（Pub/Sub）服务，即消息的发送者与消息的接收者分离的 消息传递服务 。Pub/Sub 服务包含几个关键概念，下图对此进行了说明。
Pub/Sub 服务包含以下组件：
发布者 （也称为生产者）：创建消息并将其发送（发布）到指定主题上的消息传递服务。
消息：通过服务移动的数据。
主题：代表消息源的命名实体。
架构：用于控制 Pub/Sub 消息数据格式的命名实体。
订阅：代表有兴趣接收 特定主题的消息的命名实体。
订阅者 （也称为使用者）：接收指定订阅的消息。
以下过程讨论了 Pub/Sub 服务的工作流：
两个发布者应用（发布者 1 和发布者 2）向一个 Pub/Sub 主题发送 消息。发布者 1 发送消息 A ，发布者 2 发送消息 B 。
主题本身附加到两个订阅。这两个订阅分别是订阅 1 和订阅 2 。
主题还附加到架构。
每个订阅都会从主题接收消息 A 和 B 的副本。
订阅 1 连接到两个订阅者应用，即订阅者 1 和订阅者 2 。这两个订阅者应用会从主题接收一部分消息。在此示例中，订阅者 1 从主题接收消息 B ，而订阅者 2 从主题接收消息 A 。
订阅 2 仅连接到一个名为订阅者 3 的订阅者应用。因此，订阅者 3 会从主题接收所有消息。
消息的生命周期
假设单个发布者客户端连接到某个主题。 该主题附加了一个订阅。单个订阅者连接到该订阅。
以下步骤介绍了消息在 Pub/Sub 中的流动方式：
发布者应用向 Pub/Sub 主题发送消息。
消息写入到存储空间。
在将消息写入存储空间的同时，Pub/Sub 会将消息传送给主题的所有附加订阅。
在此示例中，它是一个订阅。
订阅将消息发送给附加的订阅者应用。
订阅者向 Pub/Sub 发送确认，表明它们已处理该消息。
在每个订阅的至少一个订阅者确认消息之后，Pub/Sub 将从存储空间中删除该消息。
Pub/Sub 中消息的状态
如果向某个订阅者发送的消息未完成，Pub/Sub 会尝试不将其传送给同一订阅的任何其他订阅者。订阅者可配置一段限定的时间（称为ackDeadline），用于确认未完成的消息。该时限过后，该消息不再被视为未完成，并且可以再次传送。
Pub/Sub 服务中的消息可以有三种状态：
已确认的消息 (acked) 。订阅者应用处理从主题发送到订阅的消息后，会向 Pub/Sub 发送确认。如果某个主题上的所有订阅都已确认消息，系统将从发布消息源和存储空间中异步删除该消息。
未确认的消息 (unacked) 。如果 Pub/Sub 未在确认期限内收到确认，则消息可能会被传送多次。例如，订阅者可能会在期限到期后发送确认，或者确认可能会因暂时性网络问题而丢失。未确认的消息会继续传送，直到自消息发布之日起消息保留期限到期为止。此时，消息会过期。
否定确认的消息 (nacked) 。订阅者否定确认消息会导致 Pub/Sub 根据 默认重试 设置立即重新传送消息，而 默认重试设置可以修改。 当订阅者否定确认无效消息或无法处理的消息时，订阅者有助于确保这些消息不会丢失，并且能够成功处理。您可以使用 modifyAckDeadline 值为 0 来否定确认消息。
选择 Pub/Sub 发布和订阅模式
当有多个 Pub/Sub 发布者和订阅者客户端时，您还必须选择要设置的发布和订阅架构类型。
受支持的部分 Pub/Sub 发布-订阅模式包括：
扇入（多对一） 。在此示例中，多个发布者应用向一个主题发布消息。此主题附加了一个订阅。该订阅又连接到一个订阅者应用，该应用会从主题获取所有已发布的消息。
负载均衡（多对多） 。在此示例中，一个或多个发布者应用向一个主题发布消息。此主题附加了一个订阅，该订阅又连接到多个订阅者应用。每个订阅者应用都会获取一部分已发布的消息，并且没有两个订阅者应用会获取相同的消息子集。在这种负载均衡情况下，您可以使用多个订阅者来大规模处理消息。如果需要支持更多消息，您可以添加更多订阅者来接收来自同一订阅的消息。
扇出（一对多） 。在此示例中，一个或多个发布者应用向一个主题发布消息。此主题附加了多个订阅。每个订阅都连接到一个订阅者应用。每个订阅者应用都会从主题获取同一组已发布的消息。当主题有多个订阅时，每条消息都必须发送给代表每个订阅接收消息的订阅者。如果您需要对同一组消息执行不同的数据操作，扇出是一个不错的选择。您还可以为每个订阅附加多个订阅者，并为每个订阅者获取负载均衡的消息子集。
选择 Pub/Sub 配置选项
您可以使用以下任一选项配置 Pub/Sub 环境：
- Google Cloud 控制台
- Google Cloud CLI