本文档介绍了发布消息时的一些常见问题排查提示 标准 Pub/Sub 主题
详细了解如何向主题发布消息和不同功能。
发布延迟时间较长
发布延迟时间是指完成发布商客户端发出的发布请求所需的时间。发布延迟时间与端到端传送延迟时间不同，端到端传送延迟时间是指发布到 Pub/Sub 的消息传送到订阅者客户端所用的时间。即使另一种延迟时间类型的值较低，您也可能会发现发布延迟时间较长或端到端延迟时间。在 Pub/Sub 发布者客户端、在客户端与 Pub/Sub 后端之间传输或 Pub/Sub 后端之间传输时，都可能会出现发布延迟。您可以使用 topic/send_request_latencies 指标检查 Pub/Sub 后端中发生的发布延迟时间。后端发布延迟时间较长可能与以下因素有关：
Pub/Sub 旨在实现低延迟、高吞吐量的传送。如果主题的吞吐量较低，则与该主题关联的资源可能需要更长时间来初始化。
如果您正在使用消息存储政策，它可能会影响对主题和订阅的请求的总体延迟时间。查看使用此配置对性能和可用性的影响。
如果您的发布商客户端发现发布延迟时间明显高于指标中反映的延迟时间，这可能表明存在以下某个客户端因素：
确保不要在每次发布时都创建新的发布商。建议为每个主题、应用使用一个发布者客户端来发布所有消息。启动新的发布者对象和添加新线程会降低延迟。如果您使用 Cloud Functions 发布消息，请注意，调用也可能会影响发布延迟时间。
如果您发现默认的重试设置不足以满足您的用例，请进行相应的调整。不过，请确认新值不会过高。了解如何配置重试请求。
请注意，发布延迟时间较长可能会导致 DEADLINE_EXCEEDED 错误，下一部分将对此进行讨论。
发布操作失败并显示 DEADLINE_EXCEEDED
发布请求期间出现 DEADLINE_EXCEEDED 错误，表示请求未能在分配的时间内完成。这可能是由各种因素造成的，例如请求无法到达 Pub/Sub 服务或影响请求的性能问题。
如需验证发布请求是否到达 Pub/Sub 服务，请使用 topic/send_request_count 指标（按 response_code 分组）监控主题。此指标可帮助您确定请求在到达 Pub/Sub 主题之前是否失败。如果指标为空，则表示存在外部因素阻止消息到达 Pub/Sub 服务。此外，要排除间歇性问题的可能性，请查看错误率。如果错误率非常低，这可能是间歇性问题。
如果请求到达 Pub/Sub，则可能是以下一些原因导致发布操作失败并出现 DEADLINE_EXCEEDED 错误：
客户端瓶颈
发布失败可能是由客户端瓶颈导致的，例如内存不足、CPU 压力、线程运行状况不佳或托管发布商客户端的虚拟机中的网络拥塞。如果 Publish 调用返回 DEADLINE_EXCEEDED，可能是因为异步 Publish 调用排入队列的速度快于发送到服务队列的速度，这会逐渐增加请求延迟时间。此外，请检查以下任何一项是否有助于确定系统中可能存在的瓶颈：
检查发布消息的速度是否快于客户端发送消息的速度。通常，每个异步
Publish调用都会返回一个Future对象。如需跟踪等待发送的消息数量，请存储每次Publish调用要发送的消息数量，并仅在Future对象的回调中将其删除。确保在运行发布者的机器与 Google Cloud 之间拥有足够的上传带宽。开发版 Wi-Fi 网络的带宽通常为 1-10MB/秒，或每秒 1000-10000 条典型消息。如果在没有速率限制的情况下循环发布消息，可能会导致短时间内出现短时间内的高带宽突发现象。为避免出现这种情况，您可以在 Google Cloud 内的机器上运行发布者，或者降低发布消息的速率以匹配可用带宽。
检查您的主机和 Google Cloud 之间是否出现非常高的延迟，是否存在任何原因（例如启动网络拥塞或防火墙）。计算网络吞吐量有助于您确定不同场景的带宽和延迟时间。
归根结底，一个机器能发布的数据量有限。您可能需要尝试横向扩容或在多台机器上运行多个发布商客户端实例。测试 Cloud Pub/Sub 客户端以最大限度地提高流式传输性能演示了 Pub/Sub 如何在 CPU 数量不断增加的单个 Google Cloud 虚拟机上进行扩缩。例如，在 16 核的 Compute Engine 实例上，1KB 消息的速率可以达到 500 MB/秒到 700 MB/秒。
发布超时时长不足
如需降低发布调用的超时率，请确保在发布商客户端的重试设置中定义足够长的超时。对于重试设置，请将初始截止时间设置为 10 秒，将总超时设置为 600 秒。即使您没有积累大量未发送消息的积压，偶尔的请求延迟高峰也可能会导致发布调用超时。但是，如果您的问题是由持续的瓶颈（而不是偶尔的超时）引起的，重试更多次数可能会导致更多错误。
客户端库问题
您运行的客户端库可能版本存在已知问题。以下列表包含所有客户端库的问题跟踪器。如果您发现了影响您正在使用的客户端库版本的已知问题，请升级到该客户端库的最新版本。这样可以确保您获取到所有相关更新，包括修复和性能改进。
C++
C#
Go
Java
Node.js
PHP
Python
Ruby
架构问题
如果您的发布内容开始返回 INVALID_ARGUMENT，可能是因为有人更新了主题以更改关联架构、删除了架构或删除了与主题关联的架构修订版本。在这种情况下，请将主题的架构设置更新为与所发布消息匹配的架构和修订版本集，或调整消息格式以匹配当前架构。
邮件加密问题
如果您已将 Pub/Sub 主题配置为使用客户管理的加密密钥对已发布的消息进行加密，则发布可能会失败并显示 FAILED_PRECONDITION 错误。如果 Cloud KMS 密钥已停用，或者无法再访问通过 Cloud EKM 从外部管理的密钥，则可能会发生此错误。如需继续发布，请恢复对密钥的访问权限。