本文档简要介绍了拉取订阅、其工作流和相关属性。
在拉取订阅中，订阅方客户端向 Pub/Sub 服务器请求消息。
拉取模式可以使用 Pull 或 StreamingPull 这两个服务 API 中的一个。如需运行所选 API，您可以选择 Google 提供的高级客户端库，也可以选择自动生成的低级客户端库。您还可以选择异步和同步消息处理。
准备工作
在阅读本文档之前，请确保您熟悉以下内容：
Pub/Sub 的工作原理以及不同的 Pub/Sub 术语。
Pub/Sub 支持的不同订阅类型，以及您可能想要使用拉取订阅的原因。
拉取订阅工作流
对于拉取订阅，订阅者客户端会向 Pub/Sub 服务器发起请求以检索消息。订阅者客户端使用以下 API 之一：
大多数订阅者客户端不会直接发出这些请求。相反，客户端依赖于 Google Cloud提供的高级客户端库，该库会在内部执行流式拉取请求并异步传送消息。对于需要更好地控制消息拉取方式的订阅者客户端，Pub/Sub 使用低级且自动生成的 gRPC 库。此库可直接发出拉取或流式拉取请求。这些请求可以是同步的，也可以是异步的。
以下两张图片展示了订阅方客户端与拉取订阅之间的工作流。
拉取工作流
拉取工作流如下（请参阅图 1）：
- 订阅者客户端明确调用
pull方法，该方法将请求待传送的消息。此请求为PullRequest，如图所示。 Pub/Sub 服务器会返回零条或多条消息以及确认 ID。包含零条消息或包含错误的响应并不一定表示没有可接收的消息。此响应即为图片中所示的
PullResponse。订阅者客户端明确调用
acknowledge方法。客户端使用返回的确认 ID 来确认消息已处理，无需再次传送。
对于单个流式拉取请求，订阅者客户端可能会因连接处于打开状态而收到多个响应。相比之下，每个拉取请求仅返回一个响应。
拉取订阅的属性
您为拉取订阅配置的属性决定了您如何将消息写入订阅。如需了解详情，请参阅订阅属性。
Pub/Sub 服务 API
Pub/Sub 拉取订阅可以使用以下两个 API 之一来检索消息：
- 拉取
- StreamingPull
当您使用这些 API 接收消息时，请使用一元 Acknowledge 和 ModifyAckDeadline RPC。以下部分介绍了这两种 Pub/Sub API。
StreamingPull API
在可能的情况下，Pub/Sub 客户端库使用 StreamingPull 来最大限度提高吞吐量并缩短延迟时间。尽管您可能永远不会直接使用 StreamingPull API，但了解它与 Pull API 的不同之处却很重要。
StreamingPull API 依赖持久双向连接来接收多条消息（当有消息时）。工作流程如下：
客户端向服务器发送建立连接的请求。如果超出连接配额，服务器会返回资源耗尽错误。客户端库会自动重试配额不足错误。
如果没有错误，或者连接配额再次可用，服务器会持续向连接的客户端发送消息。
如果或当吞吐量配额超出时，服务器会停止发送消息。不过，连接并未中断。当有足够的吞吐量配额再次可用时，数据流就会恢复。
客户端或服务器最终会关闭连接。
StreamingPull API 会保持连接处于打开状态。Pub/Sub 服务器会在一段时间后定期关闭连接，以避免长时间运行的粘性连接。客户端库会自动重新打开 StreamingPull 连接。