【问题标题】：Is there a GCP equivalent to AWS SQS?是否有与 AWS SQS 等效的 GCP？
【发布时间】：2020-09-14 14:35:56
【问题描述】：
我很想了解 GCP 的 PubSub 的实现。尽管 Pubsub 似乎指向遵循发布-订阅设计模式，但它似乎比 AWS SNS（使用发布-订阅模型）更接近 AWS 的 SQS（队列）。为什么认为这是，GCP的pubSub
- 每个项目最多允许 10,000 个订阅。
- 允许过滤订阅
- 它甚至允许订购（测试版） - 这应该在某处涉及 FIFA 队列。
- 它公开了请求/响应模式的同步 api。
这让我想知道 pub/sub 中的订阅是否仅仅是 SQS 的队列。
我想听听你对这个比较的看法。造成混淆的原因是缺少 PubSub 的实现细节，并且明显的名称表明了某种设计模式。
问候，
【问题讨论】：
标签：
amazon-sqs
publish-subscribe
amazon-sns
google-cloud-pubsub
request-response
【解决方案1】：
GCP 中的消息传递部分与您在 AWS 中看到的部分略有不同。 GCP 将消息传递分为三类：
- Torrent：消息传递管道，旨在处理持久管道上的大量吞吐量。换句话说，一个人很少创建一个新的管道并在很长一段时间内通过它发送消息。洪流的缩放模式是传输大量数据的相对较少数量的管道。对于这个类别，Cloud Pub/Sub 是正确的产品。
- Trickles：消息传递管道主要是短暂的或需要向大量最终用户设备广播。这些管道的吞吐量很低，但管道的数量可能非常大。 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 中单个队列的功能。