Rest API 和 Google PubSub 之间更快的通信方法

Posted 2023-02-16

【中文标题】Rest API 和 Google PubSub 之间更快的通信方法

【英文标题】：Faster communication method between Rest API and Google PubSub

【发布时间】：2021-11-26 15:06:48

【问题描述】：

我最近开始研究 Google PubSub，并使用推送订阅在云运行实例之间传输数据。

在测试过程中，我注意到在少数情况下发布和订阅之间存在延迟。所以我直接使用了 REST API 调用，而不是通过 PubSub 发送。

请帮助我理解以下 2 项：

哪个更快？ 哪个有效？

谢谢你， KK

【参考方案1】：

直接在您的 Cloud Run 实例之间进行通信与通过 Cloud Pub/Sub 进行通信可能不仅仅意味着更快。在“良好”的情况下，即您的发布者和订阅者都已启动并运行且未超载，直接通信可能会更快。

使用 Pub/Sub 的原因主要有两点：可发现性和可靠性。为了可发现性，是否保证您的发布 Cloud Run 实例将始终知道订阅 Cloud Run 实例的 URL？数据的传输是一对一的吗？您是否曾经拥有多个想要接收消息的 Cloud Run 实例？如果是这样，您希望如何更新发布者以向两者发送消息？如果您直接通信，您可能必须向每个目标 Cloud Run 实例发出单独的请求并等待两者的响应。如果您使用 Cloud Pub/Sub，这将为您处理：您的发布 Cloud Run 实例只需向 Cloud Pub/Sub 发送一次消息，任何感兴趣的 Cloud Run 实例都将注册为订阅并接收所有消息.

使用 Pub/Sub 的另一个主要原因是可靠性。如果订阅的 Cloud Run 实例停机或过载，您的发布 Cloud Run 实例会做什么？它会缓冲消息吗？将它们写入持久存储？它如何管理缓冲区或存储并最终重新传递消息？如果 Cloud Run 实例在此期间重启会怎样？使用 Cloud Pub/Sub，您通常无需担心任何这些注意事项，因为该服务旨在提供高可用性，并在需要时快速缓冲消息，而不会影响发布者的性能。

因此，如果您只关心速度，并且您从一个 Cloud Run 实例到另一个 Cloud Run 实例的请求始终是一对一的，那么您将始终知道目标 Cloud Run 实例的地址，您可以不用实现更复杂的缓冲（基本上，保证最多一次交付），那么直接调用可能就可以了。

但是，如果需要考虑这些因素中的任何一个，那么 Cloud Pub/Sub 将是一个更好的选择。由于它正在跳过多个步骤，因此它可能会更慢。您可能可以做一些事情来确保将延迟降到最低。两种常见的是：

确保您只实例化发布者客户端一次并重复使用它，而不是为每次发布重新创建客户端。 在您的 publisher batch settings 中，将 maxMessages 设置为 1，以便通过调用 publish 收到每条消息后立即发送。如果您的消息吞吐量相对较低，这将很有帮助。如果您的吞吐量很高，那么关键是确保您不要同步等待发布的结果，尤其是在循环发布消息的情况下。通过异步等待，您可以将更多消息批处理在一起，从而更有效地发送它们。

因此，对于有效的问题，没有单一的答案。这在很大程度上取决于用例和所需的行为。但很有可能，从您必须做的工作量的效率角度来看，Pub/Sub 是更好的选择。

【讨论】：

感谢您的详细解释。这就是我一直在寻找的。显然，在测试 pubsub 时，我们注意到在极少数情况下会出现大约 5 分钟的错误，这会导致系统崩溃。 pubsub 中是否会出现这种行为？

什么样的错误？

从发布到订阅端接收有很大的延迟（>3分钟）。

我上面提到的几点将是最好的研究。第一个要回答的问题是，发布延迟还是订阅延迟？您需要查看您的发布延迟是多少（从调用发布到将来获得响应）。如果这很短，那么问题可能出在订户身上。如果您正在 nacking 消息或让 ack 截止日期到期，则服务会在所有消息的传递上退缩，这可能会延迟获取其他消息。您可以查看 subscription/push_request_latencies Cloud Metric 以获取此信息。

再次感谢您的解释。我还有两个查询，我们如何测量发布延迟？如果一条消息被 nack 或截止日期过期，它会影响发布给该订阅者的所有后续消息吗？根据您的解释，我的理解是否正确。