本文档介绍了 Pub/Sub StreamingPull 订阅的一些常见问题排查提示。StreamingPull 订阅使用 StreamingPull API。
如需详细了解 StreamingPull 订阅，请参阅拉取订阅者指南。
StreamingPull 的错误率为 100%
StreamingPull 流始终以不正常状态关闭。与一元 RPC 不同，StreamingPull 的此状态仅表示数据流已中断。请求未失败。因此，虽然 StreamingPull API 的错误率可能高达 100%，但这是设计使然。
不满足前提条件、不可用或未找到错误
由于 StreamingPull 流始终以错误关闭，因此在诊断错误时检查数据流终止指标并没有什么帮助。相反，请专注于 StreamingPull 响应指标，例如 subscription/streaming_pull_response_count。
请查找以下错误：
以下情况下可能会发生的不满足前提条件错误：
Pub/Sub 尝试使用已停用的 Cloud KMS 密钥解密消息。
如果订阅积压中有消息使用已停用的 Cloud KMS 密钥加密，则会暂停订阅。
当 Pub/Sub 无法处理请求时可能发生的不可用错误。这很可能是一种暂时情况，客户端库会重试请求。
“未找到”错误：如果订阅已被删除或订阅根本不存在，就可能会发生这种错误。当您提供的订阅路径无效时，就会发生后一种情况。
StreamingPull 订阅中的大量小消息积压
gRPC StreamingPull 堆栈针对高吞吐量进行了优化，因此会缓冲消息。如果您尝试处理积压的大量简短消息，则可能会看到多次传送的消息。 这些消息可能无法在客户端之间有效地进行负载均衡。
Pub/Sub 服务和客户端库用户空间之间的缓冲区大约为 10 MB。要了解此缓冲区对客户端库行为的影响，请考虑以下示例：
订阅中积压了 10,000 条 1-KB 消息。
单线程客户端实例按顺序处理每条消息需要一秒钟。
第一个为该订阅建立 StreamingPull 至服务的连接的客户端实例用所有 10,000 条消息填充其缓冲区。
处理该缓冲区需要 10,000 秒（将近三个小时）。
在此期间，一些缓冲的消息超出了其确认时限，并重新发送至同一客户端，导致出现重复。
当多个客户端实例正在运行时，卡在一个客户端的缓冲区中的消息不可供任何其他客户端实例使用。如果对 StreamingPull 使用流控制，则不存在这种情况。服务不会同时拥有全部 10 MB 消息，并且能够有效地对多个订阅者的消息进行负载均衡。