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

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

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

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

根据发布操作的响应采取行动

当高级别客户端库的发布调用完成时，它会返回一个包含操作结果的 future 对象。为避免阻塞各个发布请求，请异步处理结果。您应根据自己的使用场景，确定处理失败的最佳方式。支持无线更新的选项包括：

  • 记录错误，不执行其他操作（如果您的使用情形不需要成功发布所有消息）。
  • 在出现可能短暂的失败（例如 Deadline exceeded 错误）时重试发布。
  • 将消息持久保存到文件或存储空间，以便稍后重试发布，尤其是在发生需要用户干预的错误（例如 Not found 或 Permission denied）时。
  • 将错误传播到向您发送您尝试发布的消息的上游服务。

如果您认为 Pub/Sub 未按预期将消息传送给订阅者，请验证您是否在跟踪发布结果，以及发布是否成功。

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

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

配置批量消息

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

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

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

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

使用批处理时，增加这两种类型的延迟时间是为了提高效率和吞吐量。

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

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

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

为瞬时消息峰值配置流控制

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

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

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

如需检查您的客户端库是否支持发布者流控制并配置该功能，请参阅流控制。

了解网络带宽和延迟时间

发布商吞吐量受网络带宽和发送的请求数量的限制。如果您的带宽良好，但网络延迟时间较长，您就不希望通过许多小请求来使系统不堪重负。发布商端流量控制有助于解决客户端网络问题。

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

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

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

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

  • 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 的主题消息存储政策提供了一种方法，用于确保发布到主题的消息绝不会保留在您指定的一组Trusted Cloud by S3NS 区域中，而无论发布请求来自哪里。

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

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

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

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

如果您使用消息排序，请确保以下事项：

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

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

最佳做法摘要

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

主题 任务
配置消息保留 在发布或启用消息保留功能之前，请先附加订阅。
在发布请求中批量处理消息 批量处理或分组处理消息，以提高发布者的效率并以更高的吞吐量发送消息。
流控制 在发布方设置中配置流控制，以处理瞬时流量峰值。
测试 Pub/Sub 客户端以最大限度地提升流式传输性能 通过增加可用的机器核心数和网络带宽来提高发布商吞吐量。
重试请求 仅当您发现默认设置无法满足您的使用情形时，才调整发布商重试政策的指定值。
配置邮件存储政策 使用消息存储政策，将磁盘上的消息数据仅存储在特定位置。
在发布中使用排序键时，请使用位置端点 使用有序的消息传递时，请使用位置端点，并配置一个恢复发布函数来处理发布失败的情况。

后续步骤