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

Question

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

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

请帮助我理解以下 2 项：

1. 哪个更快？
2. 哪个有效？

谢谢你，
KK

Answer 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 将是一个更好的选择。由于它正在跳过多个步骤，因此它可能会更慢。您可能可以做一些事情来确保将延迟降到最低。两种常见的是：

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

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