本文档可帮助您选择适合您业务需求的 Pub/Sub 订阅类型。
Pub/Sub 提供以下类型的订阅：
拉取订阅使用订阅方客户端向 Pub/Sub 服务器请求消息。
推送订阅使用 Pub/Sub 服务器向订阅者应用发起请求来传送消息。
导出订阅：将消息直接导出到 Google Cloud资源。这些订阅包括：
BigQuery 订阅会将数据导出到 BigQuery 表中。
Cloud Storage 订阅将数据导出到 Cloud Storage 存储桶。
Pub/Sub 订阅比较表
下表提供了一些指导来帮助您为应用选择适当的传送机制：
| Pub/Sub 订阅支持的功能 | ||
|---|---|---|
| 使用场景 | 拉取订阅 |
|
| 推送订阅 |
|
|
| 导出订阅 |
|
|
| 端点 | 拉取订阅 | 互联网上具有授权凭据的任何设备都能调用 Pub/Sub API。 |
| 推送订阅 |
可以在公共网络上访问的具有非自签名证书的 HTTPS 服务器。 接收端点可以与 Pub/Sub 订阅分离，因而来自多个订阅的消息可以发送到单个端点。 |
|
| 导出订阅 | 订阅会将消息写入 Google Cloud 资源，例如 BigQuery 表或 Cloud Storage 存储桶。 | |
| 负载均衡 | 拉取订阅 | 多个订阅者可以对同一订阅进行拉取调用。 每个订阅者都会收到一部分消息。 |
| 推送订阅 |
推送端点可以充当负载平衡器。 |
|
| 导出订阅 |
Pub/Sub 服务会自动平衡负载。 |
|
| 配置 | 拉取订阅 |
不需要进行配置。 |
| 推送订阅 |
|
|
| 导出订阅 | 订阅导出到的 Google Cloud 资源必须存在，并且已配置适当的权限。 | |
| 流控制 | 拉取订阅 | 订阅者客户端控制传送速率。订阅者可以动态修改确认时限，从而允许将处理消息所用时间设为任意长度。 |
| 推送订阅 | Pub/Sub 服务器会自动实施流控制。客户端无需处理消息流。不过，可以通过传回 HTTP 错误来指示客户端无法处理当前消息负载。 | |
| 导出订阅 | Pub/Sub 会自动实施流控制，以优化将消息写入目标 Google Cloud资源的过程。 | |
| 效率和吞吐量 | 拉取订阅 | 通过批量传送、确认和大规模并行处理，在低 CPU 和带宽下实现高吞吐量。如果使用频繁的轮询来最大限度缩短消息传送时间，则可能效率低下。 |
| 推送订阅 | 每个请求传送一条消息并限制未完成消息的最大数量。 | |
| 导出订阅 | Pub/Sub 可动态处理可伸缩性问题。 | |
何时使用导出订阅
如果没有导出订阅，您需要拉取或推送订阅以及订阅者（例如 Dataflow）来读取消息并将其写入 Google Cloud 资源。如果消息在存储之前不需要进行额外处理，则无需运行 Dataflow 作业。
导出订阅具有以下优势：
部署简单。您可以通过控制台、 Google Cloud CLI、客户端库或 Pub/Sub API 中的单个工作流设置导出订阅。
费用低。减少了包含 Dataflow 作业的类似 Pub/Sub 流水线的额外费用和延迟时间。 此费用优化适用于在存储之前不需要进行额外处理的消息传递系统。
监控工作量极少。导出订阅是多租户 Pub/Sub 服务的一部分，不需要您运行单独的监控作业。
灵活性。BigQuery 订阅可以使用所附加主题的架构，而从 Pub/Sub 写入 BigQuery 的基本 Dataflow 模板无法使用该架构。同样，Cloud Storage 订阅提供基于文件大小和经过时间的、可配置的文件批处理选项，而从 Pub/Sub 写入 Cloud Storage 的基本 Dataflow 模板中无法配置这些选项。
不过，对于需要在将数据存储到Google Cloud 资源（例如 BigQuery 表或 Cloud Storage 存储桶）之前进行一些数据转换的 Pub/Sub 系统，我们仍建议使用 Dataflow 流水线。
如需了解如何使用 Dataflow 将数据从 Pub/Sub 流式传输到 BigQuery 并进行转换，请参阅从 Pub/Sub 流式传输到 BigQuery。
如需了解如何使用 Dataflow 将数据从 Pub/Sub 流式传输到 Cloud Storage 并进行转换，请参阅使用 Dataflow 从 Pub/Sub 流式传输消息。
后续步骤
了解每种订阅类型的工作流程：