6

我很想了解 GCP 的 PubSub 的实现。尽管 Pubsub 似乎指向遵循 Publish-Subscribe 设计模式，但它似乎比 AWS SNS（使用发布-订阅模型）更接近 AWS 的 SQS（队列）。为什么认为这是，GCP的pubSub

  1. 每个项目最多允许 10,000 个订阅。
  2. 允许过滤订阅
  3. 它甚至允许订购（测试版） - 这应该在某处涉及 FIFA 队列。
  4. 它公开了请求/响应模式的同步 api。

这让我想知道 pub/sub 中的订阅是否仅仅是 SQS 的队列。我想听听你对这个比较的看法。混乱是由于缺乏 PubSub 的实现细节和明显的名称表明某种设计模式。

问候，

4

2 回答 2

19

GCP 中消息传递的划分与您在 AWS 中看到的略有不同。GCP 将消息传递分为三类：

  • Torrents：消息传递管道，旨在处理持久管道上的大量吞吐量。换句话说，一个人很少创建一个新的管道并在很长一段时间内通过它发送消息。Torrent 的缩放模式是传输大量数据的相对较少数量的管道。对于这个类别，Cloud Pub/Sub是合适的产品。
  • 涓涓细流：主要是短暂的或需要广播到大量最终用户设备的消息传递管道。这些管道的吞吐量很低，但管道的数量可能非常大。Firebase Cloud Messaging是适合此类别的产品。
  • 队列：消息传递管道，可以更好地控制端到端的消息传递。这些管道的吞吐量并不高，管道的数量也不是很大，但支持更高级的属性，例如延迟或取消消息传递的能力。Cloud Tasks属于这一类，尽管 Cloud Pub/Sub 也采用了一些功能，使其越来越适用于这个用例。

所以 Cloud Pub/Sub 是 SQS+SNS 的发布/订阅方面，其中 SNS 被用作将消息分发到不同 SQS 队列的一种手段。它还可以用作 Kinesis 的大数据摄取机制。Firebase Cloud Messaging 涵盖了旨在到达最终用户设备的 SNS 部分。Cloud Tasks（以及越来越多的 Cloud Pub/Sub）在 SQS 中提供单个队列的功能。

于 2020-09-14T14:59:39.990 回答
-1

您说 GCP PubSub 接近 AWS SQS 是正确的。据我所知，GCP 中没有确切的 SNS 工具，但我认为最接近的工具是 GCM（Google Cloud Messaging）。您不是唯一有此查询的人： GCP 堆栈中的 AWS SNS 等效项

于 2020-09-14T14:45:36.567 回答