本文档假定您已熟悉在订阅方客户端中订阅 Pub/Sub 主题并接收消息的过程。
如果您刚接触 Pub/Sub，请参阅某个快速入门指南，了解如何使用控制台、Google Cloud CLI 或客户端库运行 Pub/Sub。
选择合适的订阅
Pub/Sub 提供标准订阅，例如推送和拉取订阅。除了标准订阅之外，Pub/Sub 还提供导出订阅，可让您直接将消息存储到Google Cloud 资源，而无需将 Dataflow 用作中介。例如，BigQuery 订阅会将消息存储在 BigQuery 表中。
建议在以下场景中使用推送订阅：
您不得在订阅方应用中添加任何将客户端库作为依赖项导入的代码。
订阅者客户端无法发出任何出站请求。
您希望使用同一实例处理来自不同主题和订阅的消息，并且订阅方客户端不知道订阅列表。
对于一般情况，我们建议使用高级客户端库。如果您改用单元操作符拉取，请勿将 returnImmediately 设置为 true。将其设置为 true 会对拉取性能产生不利影响。returnImmediately 字段现已废弃。
如需比较所有订阅类型并选择最符合您业务需求的订阅类型，请参阅 Pub/Sub 订阅对比表。
如需了解导出订阅的优势，请参阅何时使用导出订阅。
先处理消息，然后再确认消息
默认情况下，Pub/Sub 会在消息被确认后从订阅中舍弃消息。如果您未在发送确认之前处理消息，并且处理失败，则该服务不会重新传送消息。但是，如果您已配置保留已确认的消息或主题保留，并执行了查找操作，则不受此影响。
如果您有高延迟订阅方，则可能需要为流量控制和租约管理设置自定义值。
针对瞬时流量峰值配置订阅方流量控制
通过订阅方流量控制，您可以防止订阅方因流量激增而超载。这可以让自动扩缩机制有时间响应增加的负载，也可以将负载处理时间延长到更长的时间。前一种方法可缩短延迟时间，而后一种方法可节省费用。
如需配置流量控制，您必须为 maximum outstanding messages 和 total outstanding message bytes 设置适当的值。这些流控制变量的默认值和变量名称可能会因客户端库而异。
待处理消息的数量上限用于定义向客户端传送的消息数量上限，其中 Pub/Sub 尚未收到确认或否定确认。
待处理消息总字节数用于定义传送给客户端且 Pub/Sub 尚未收到确认或否定确认的消息的总大小上限。
如果超出其中任一选项的限制，订阅方客户端将不会拉取更多消息。此行为会一直持续，直到已拉取的消息收到确认或否定确认为止。这样，您就可以在吞吐量与运行更多订阅者相关的费用之间进行权衡。
订阅中有序消息传递的最佳实践
如果您使用消息排序，请确保：
选择 StreamingPull 或 Pull 订阅。对于推送订阅，Pub/Sub 一次只能支持每个排序键有一个待处理消息。在这种情况下，发送并行推送请求类似于针对同一排序键发送多批消息，以便同时拉取订阅者。因此，对于经常使用相同排序键发布多条消息或延迟时间极其重要的主题，不建议使用推送订阅。
在订阅中启用消息排序。在发布端，如果您发送的消息带有排序键且位于同一区域，则可以将订阅者配置为按顺序接收这些消息。在订阅方，仅为您希望接收有序消息的订阅启用消息排序属性。根据媒体资源状态，附加到主题的每个订阅都可以确定自己是否需要有序传送，而不会相互影响。
按顺序确认消息。使用有序传送时，系统会按排序键处理早期消息的确认，然后再处理后续消息的确认。例如，如果消息 1、2 和 3 具有相同的排序键，并且您收到了所有这些消息，但仅确认了消息 3，那么在消息 1 和 2 也得到确认之前，该服务不会将消息 3 视为已确认。如果系统从未收到消息 1 和 2 的确认，则会重新传送消息 1、2 和 3。
最佳做法摘要
下表总结了本文档中建议的最佳实践：
| 主题 | 任务 |
|---|---|
| 选择订阅类型 | 选择适合您业务需求的订阅类型。如果您的订阅支持，还应使用高级客户端库。 |
| 重放已确认的消息 | 请先处理消息，然后再确认消息。或者，请进行跳转操作配置，以免丢失已确认的消息。 |
| 流控制 | 在订阅者设置中配置流控制，以确保在自动扩缩生效或时间过后之前，订阅者不会过载。 |
| 对消息排序 | 使用有序消息传递时，请选择 StreamingPull 或 Pull，在订阅中启用消息排序，并按顺序确认消息。 |