发布到 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 尝试传送消息的次数以及每次尝试之间的时间间隔。

例如，在适用于 Pub/Sub 的 Java 客户端库中，发布商客户端包含以下值：

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

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

  • maxtriesDelay。发布者在重试发布操作之前等待的最大延迟时间。默认值为 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 客户端以最大限度地提高流式处理性能 随着可用机器核心和网络带宽的增加，提高发布者吞吐量。
重试请求 仅当您发现默认设置不足以满足您的用例时，才调整发布商重试政策的指定值。
配置消息存储政策 使用消息存储政策可以仅在特定位置将消息数据存储在磁盘上。
在发布时使用排序键时使用位置端点 使用有序消息传递时，请使用位置端点并配置恢复发布功能以处理发布失败的情况。

后续步骤