适用于事件驱动型系统和流式分析的消息传递和事件提取服务。 Pub/Sub 是一种异步消息传递服务，可将产生事件的服务与处理事件的服务分离开。 可以将 Pub/Sub 用作消息传递的中间件，或是用在流式分析流水线上提取和传送事件。 Pub/Sub 能够长时间存储消息，并能够大规模实时传送消息，而且可用性高，性能稳定。Pub/Sub 服务器可在全球所有 Google Cloud 区域运行。 Pub/Sub 对应的 Kafka.
优势
- 与 Dataflow 和 BigQuery 相集成，共同构成 Google Cloud 原生流式分析解决方案
- 支持从零到每秒数百 GB 的吞吐量，可实现自动扩缩和自动预配
- 面向发布者和订阅者的独立配额计算和结算功能
- 可在全球范围内路由消息，从而简化多地区系统
- 传送推送消息和拉取消息
核心概念
- 主题：发布者向其发送消息的已命名资源。
- 订阅：代表从单个特定主题传送到订阅应用的消息流的已命名资源。
- 消息：发布者向主题发送并最终传送给订阅者的数据和（可选）特性的组合。
- 消息特性：发布者可以为消息定义的键值对。例如，可以将键 iana.org/language_tag 和值 en 添加到消息中，将消息标记为可供英语订阅者阅读。
发布者-订阅者关系
发布者应用创建主题并将消息发送到主题。订阅者应用创建对主题的订阅以便从其接收消息。 通信配置可以为一对多（扇出 fan-out）、多对一（扇入 fan-in）和多对多。
注：此处的扇出、扇入，可以理解为折扇的形式。
如上图所示，可以多个生产者对一个消费者，也可以一个生产者对多个消费者（当然，可以多个生产者，对多个消费者。）
消息
消息格式
消息由包含消息数据和元数据的字段组成，在消息中至少指定以下内容：
- 消息数据 data
- 排序键 orderingKey
- 包含其他元数据的属性 attributes
如果使用 REST API，则消息数据必须采用 base64 编码。
Pub/Sub 服务将以下字段添加到消息中：
- 主题专属的消息 ID messageId
- 在消息发布时由服务器分配。保证在主题中是唯一的。此值可以由通过订阅接收PubsubMessage的订阅者读取。pull call或push delivery。这个字段不能有发布者填充。
- Pub/Sub 服务接收消息的时间的时间戳
批处理请求
消息可以根据请求大小（以字节为单位）、消息数量和时间分批。
消息排序
按顺序接受消息
如果消息带有相同的排序键并且位于同一地区，则您可以启用消息排序并按 Pub/Sub 服务接收这些消息的顺序来接收消息。 因为Pub/Sub 会为每条消息至少传送一次，因此 Pub/Sub 服务可能会重新传送消息。如果您按顺序接收消息，并且 Pub/Sub 服务重新传送带有排序键的消息，则 Pub/Sub 也会重新传送带有相同排序键的后续消息，从而保持顺序。Pub/Sub 服务会按消息最初接收的顺序重新传送这些消息。 按顺序接受消息可能会增加延迟时间。 设置消息排序属性后，Pub/Sub 服务会按照接收消息的顺序来传送带有相同排序键的消息。例如，如果发布者发送两条带有相同排序键的消息，则 Pub/Sub 服务会先传递最早的消息。
常见使用场景
- 平衡网络集群中的工作负载。例如，可以在多个工作器（例如 Google Compute Engine 实例）之间高效地分配大量任务。
- 实现异步工作流。例如，订单处理应用可以对某主题下订单，由一个或多个工作器处理该订单。
- 分发事件通知。例如，每当新用户注册时，接受用户注册的服务可以发送通知，并且下游服务可以订阅以接收该事件的通知。
- 刷新分布式缓存。例如，应用可以发布无效化事件以更新发生更改的对象的 ID。
- 将日志记录到多个系统。例如，Google Compute Engine 实例可以将日志写入到监控系统、数据库（方便以后查询）等等。
- 来自各种进程或设备的数据流。例如，住宅传感器可以将数据流式传输到托管在云端的后端服务器。
- 改进可靠性。例如，单地区 Compute Engine 服务可以通过订阅一个公用主题来在其他地区中运行，以便在地区或区域中发生故障时恢复服务。
其他
- Pub/Sub 旨在将事件的发布者与这些事件的订阅者分离开来。发布者无需了解其订阅者的任何信息。 因此，Pub/Sub 除了能保证传送消息之外，还使发布者无法控制消息的传送。
- 订阅者，既可以主动推送事件给他 Push，也可以由他自己进行拉取 Pull
在流式分析中的位置
其他
- 每月前 10GB 免费
- 可以设置死信，例如传送尝试达到指定次数时（5~100）,放入死信之中。死信会存储消息，以允许稍后访问。