订阅 Pub/Sub 主题的最佳做法

在订阅过程中，订阅者客户端接收来自 Pub/Sub 主题的消息。以下是订阅 Pub/Sub 的一些最佳实践。

本文档假定您已熟悉在订阅者客户端中订阅 Pub/Sub 主题和接收消息的过程。

如果您刚开始接触 Pub/Sub，请参阅其中一份快速入门指南，了解如何使用控制台、gCloud CLI 或客户端库运行 Pub/Sub。

选择合适的订阅

Pub/Sub 提供标准订阅，如推送订阅和拉取订阅。pushpush除了标准订阅之外，Pub/Sub 还提供导出订阅，可让您将消息直接存储到 Google Cloud 资源，而无需使用 Dataflow 作为中间方。例如，BigQuery 订阅会将消息存储在 BigQuery 表中。

建议在以下情况下使用推送订阅：

  • 您无法在订阅者应用中包含任何将客户端库作为依赖项导入的代码。

  • 订阅者客户端无法发出任何传出请求。

  • 您希望使用同一实例处理来自不同主题和订阅的消息，而订阅者客户端不知道订阅列表的情况。

对于一般情况，我们建议使用高级客户端库。如果您改用一元拉取，请勿将 returnImmediately 设置为 true，将其设置为 true 会对拉取性能产生不利影响。字段 returnImmediately 现已弃用。

在确认消息之前对其进行处理

默认情况下，Pub/Sub 会在确认消息后从订阅中舍弃该消息。如果您在发送确认之前未处理消息，并且处理失败，则服务不会重新提交消息。例外情况是，您配置了保留已确认消息或主题保留并执行了搜索操作。

如果您有高延迟订阅者，则可能需要为流控制和租期管理设置自定义值。

配置针对瞬时流量高峰的订阅者流控制

借助订阅者端的流控制，您可以防止订阅者因流量高峰而过载。它既可以为自动扩缩机制留出时间来响应负载增加的情况，也可以将负载处理分散到较长的一段时间。前一种方法可以缩短延迟时间，而后一种方法可以节省费用。

如需配置流控制，您必须为 maximum outstanding messages 和 total outstanding message bytes 设置适当的值。这些流控制变量的默认值和变量名称可能因客户端库而异。

  • 未完成消息数量上限定义了传递给客户端但未收到确认或否定确认的消息的数量上限。

  • 未完成消息总字节数定义已传送给 Pub/Sub 尚未收到确认或否定确认的客户端的消息总大小上限。

如果超出了其中某个选项的限制，订阅者客户端便不会拉取更多消息。此行为将持续到已拉取的消息得到确认或否定确认。通过这种方式，您可以通过与运行更多订阅者相关的费用来权衡吞吐量。

在订阅中使用有序消息传递的最佳实践

如果您使用消息排序，请确保：

  • 选择 StreamingPull 或“拉取”订阅。对于推送订阅，Pub/Sub 一次仅支持每个排序键有一条未完成的消息。在这种情况下，发送并行推送请求类似于针对同一排序键发送多批消息以同时拉取订阅者。因此，对于经常使用相同的排序键发布多条消息或对延迟极为重要的主题，不建议使用推送订阅。

  • 在订阅中启用消息排序。在发布者端，如果您使用排序键发送消息并在同一区域中，则可以将订阅者配置为按顺序接收这些消息。在订阅者端，仅为您希望接收有序消息的订阅启用消息排序属性。根据属性状态，附加到主题的每个订阅都可以确定它们是否需要按顺序传送，而不会相互影响。

  • 按顺序确认消息。使用有序传送时，只有按排序键处理对较早消息的确认后，系统才会处理后续消息的确认。例如，如果您有消息 1、2 和 3 具有相同的排序键，但是您收到了所有消息，但只确认了消息 3，则服务在消息 1 和 2 也得到确认之前，不会将消息 3 视为已确认。如果从未收到对消息 1 和 2 的确认，则消息 1、2 和 3 将全部重新提交。

最佳做法摘要

下表总结了本文档中建议的最佳实践：

主题 任务
选择订阅类型 根据您的业务需求选择合适的订阅类型。如果您的订阅支持，您也可以使用高层级客户端库。
重放已确认的消息 在确认消息之前对其进行处理。或者，为还原操作进行配置，以免丢失已确认的消息。
流控制 在订阅者设置中配置流控制，以确保在自动扩缩启动或时间过去之前，订阅者不会过载。
为邮件排序 使用有序消息传递时，请选择 StreamingPull 或拉取，在订阅中启用消息排序，并按顺序确认消息。

后续步骤