发布到 Pub/Sub 主题的最佳实践

在发布过程中，发布者客户端向 Pub/Sub 主题发送消息。下面是向 Pub/Sub 发布消息的一些最佳实践。

本文档假定您已熟悉向 Pub/Sub 主题发布消息的过程。

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

在开始发布之前附加订阅或启用主题保留

如果您开始向没有附加订阅者的主题发布消息，系统不会保留这些消息。这些消息无法传送到随后附加的订阅。因此，在开始发布消息之前，请执行以下任一操作：

配置批量消息传递

在 Pub/Sub 中，批量消息传递是指将多条消息合并为一批消息，并在单个发布请求中发布该批消息的过程。如果您使用客户端库发布消息，则系统会默认启用批处理功能。消息批处理（或分组）有助于发布商提高效率，并以更高的吞吐量发送消息。批量处理可降低发布数据的费用。不过，批处理也会导致单条消息出现延迟，因为发布商会等待批次填满后再发布批次。

Pub/Sub 中的延迟时间可以分为两种类型：

  • 端到端延迟时间是指消息从发布者发布并传送给相应订阅者进行处理所需的时间。

  • 发布延迟时间是指发布消息所用的时间。

使用批处理时，提高这两种延迟时间是提高效率和吞吐量的代价。

您可以在客户端库中根据消息请求大小、消息数量和时间对消息进行批处理。配置批处理设置时，您可以在费用、吞吐量和延迟时间之间找到适合您的用例的平衡点。

批量消息传递变量的默认值和变量名称可能会因客户端库而异。您可以在客户端库中指定一个或全部三个值。如果满足批量消息传递变量的任一值，客户端库就会发布下一批消息。

如需为发布方客户端配置批量消息传递，请参阅在发布请求中批量发送消息。

针对瞬时消息高峰配置流量控制

如果发布方客户端必须处理大量消息，发布请求可能会开始在内存中累积，直到消息因出现 Deadline exceeded 错误而无法发布。

如需解决发布消息的瞬时峰值问题，您可以在发布方设置中使用流控制。发布商端流量控制可防止因待处理的请求过多而导致发布商客户端资源过载。如果发布商客户端在内存、CPU 或线程方面受到限制，则会生成大量 Deadline exceeded 错误。

如需在客户端库中配置流控制，请为未完成消息数上限和未完成消息字节数上限变量设置适当的值。这些值可平衡消息吞吐量和系统容量。

如需检查您的客户端库是否支持发布商流控制以及如何进行配置，请参阅流控制。

了解网络带宽和延迟时间

发布商吞吐量受网络带宽和发送的请求数量的限制。如果带宽较高，但网络延迟时间较长，则不应通过大量小请求使系统过载。发布商端流量控制有助于解决客户端网络问题。

发布商吞吐量也受 CPU 和内存限制。可用的机器核心越多，您可以设置的线程数就越多，发布吞吐量就越高。如需进一步了解如何最大限度地提升流式传输性能，请参阅测试 Cloud Pub/Sub 客户端以最大限度地提升流式传输性能。

调整失败发布的重试请求变量

当发布商客户端发布消息时，您可能会看到发布失败。这些失败通常是由客户端瓶颈导致的，例如服务 CPU 不足、线程运行状况不佳或网络拥塞。publisher retry policy 用于确定消息传送失败时的行为。重试政策定义了 Pub/Sub 尝试传送消息的次数以及每次尝试之间的时间长度。

例如，在 Java 版 Pub/Sub 客户端库中，发布方客户端包含以下值：

  • initialRetryDelay。发布商在重试发布操作之前等待的初始延迟时间。默认值为 100 milliseconds。

  • retryDelayMultiplier。用于计算重试间隔时间的乘数。默认值为 4。这意味着，第二次重试之间的延迟时间最多为 100 milliseconds * 4 = 400 milliseconds，第三次重试之间的延迟时间最多为 400 milliseconds * 4 = 1600 milliseconds。

  • maxRetryDelay。发布商在重试发布操作之前等待的最长延迟时间。默认值为 60 seconds。

  • initialRpcTimeout。发布商等待 RPC 调用完成的初始超时时间。默认值为 5 seconds。

  • rpcTimeoutMultiplier。用于计算 RPC 超时时间的乘数。默认值为 4.0。这意味着，第二次重试的 RPC 调用超时时间最多为 5 seconds * 4 = 20 seconds，第三次重试的 RPC 调用超时时间最多为 10 seconds * 4 = 40 seconds。

  • maxRpcTimeout。发布端等待 RPC 调用完成的最长超时时间。默认值为 600 seconds。

  • totalTimeout。发布操作的总超时时间。这包括等待 RPC 调用完成的时间，以及重试之间等待的时间。默认值为 600 seconds。

只有在您发现默认重试设置不适用于您的用例时，才应调整指定值。例如，发布大量消息时，您无需增加 initialRetryDelay 和 maxRetryDelay 值。不过，在这种情况下，您可以调整流量控制和批处理。如果您是通过不稳定的互联网连接或带宽受限的连接发布内容，可以尝试调整 initialRpcTimeout、maxRpcTimeout 和 rpcTimeoutMultiplier 变量的值。如需了解建议的值，请参阅发布操作失败并显示 DEADLINE_EXCEEDED。

使用消息存储政策确保数据本地性

Pub/Sub 的主题消息存储政策提供了一种方法，用于确保发布到主题的消息绝不会保留在您指定的一组 Google Cloud 区域中，而无论发布请求来自哪里。

使用消息存储政策指定允许 Pub/Sub 在磁盘上存储消息数据的 Google Cloud 区域列表。如果将消息发布到此列表中未列出的区域，系统会将请求转发到最近的允许区域进行处理。您可以针对主题配置此政策，也可以将其作为组织政策应用于项目、项目文件夹或整个组织。配置组织政策后，只能以不违反组织政策的方式更改各个主题政策。

例如，在欧洲运营的公司可能会使用消息存储政策，以确保所有数据都存储在欧盟区域，从而遵守当地法律。

如需了解详情，请参阅配置消息存储政策。

发布中有序消息传递的最佳实践

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

  • 使用位置端点。消息的顺序会保留在发布端和区域内。换句话说，如果您要将消息发布到多个区域，则只有同一区域内的消息会以一致的顺序传送。如果您的所有消息都发布到同一区域，但订阅者分布在多个区域，则订阅者会按顺序接收所有消息。使用位置端点将消息发布到同一区域。

  • 配置接续发布函数。当客户端库重试某个请求且消息带有排序键时，无论重试设置如何，客户端库都会不断重试该请求。如果出现不可重试的错误，则客户端库无法发布消息，并会停止发布带有相同排序键的其他消息。当您准备好继续发布已发布失败的排序键时，请调用 resumePublish 方法。

最佳做法摘要

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

主题 任务
配置消息保留 请先附加订阅，然后再发布消息或启用消息保留功能。
在发布请求中批量处理消息 批量或分组发送消息，以提高发布商的效率并以更高的吞吐量发送消息。
流控制 在发布方设置中配置流量控制，以处理瞬时流量高峰。
测试 Pub/Sub 客户端以最大限度地提升流式传输性能 增加可用机器核心数和网络带宽，从而扩展发布商吞吐量。
重试请求 仅当您发现默认设置不适用于您的用例时，才应调整发布商重试政策的指定值。
配置消息存储政策 使用消息存储政策可将消息数据仅存储在特定位置的磁盘上。
在发布时使用排序键时，请使用位置端点 使用有序消息传递时，请使用位置端点，并针对发布失败配置恢复发布函数。

后续步骤