是否有等效于 AWS SQS 的 GCP？

Question

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

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

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

问候，

Answer 1

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

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

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

Answer 2

您说 GCP PubSub 接近 AWS SQS 是正确的。据我所知，GCP 中没有可用的确切 SNS 工具，但我认为最接近的工具是 GCM（Google Cloud Messaging）。您不是唯一有过此查询的人： AWS SNS equal in GCP stack