问题描述
我很想了解GCP的PubSub的实现。尽管Pubsub似乎指向遵循Publish-Subscribe设计模式，但它似乎比AWS SNS（使用publish-subscribe模型）更接近AWS的SQS（队列）。为什么认为这是GCP的pubSub
这让我想知道发布/订阅中的订阅是否仅仅是SQS的队列。 我希望您对此比较发表意见。造成这种混乱的原因是，PubSub上没有实现细节，而且明显的名称表示某种设计模式。
此致
解决方法
GCP中消息传递的划分与您在AWS中看到的划分略有不同。 GCP将消息传递分为三类：
- 流量：设计用于处理持久性管道上的大量吞吐量的消息传递管道。换句话说，很少会创建新的管道，并且会长时间发送消息。洪流的缩放模式是传输大量数据的管道数量相对较少。对于此类别，Cloud Pub/Sub是正确的产品。
- ckle锁：主要是短暂的消息传递管道，或需要广播到大量最终用户设备的消息传递管道。这些管道的吞吐量很低，但是管道的数量可能非常多。 Firebase Cloud Messaging是适合该类别的产品。
- 队列：消息传递管道，可以更好地控制端到端消息传递。这些管道并不是真正的高吞吐量，也不是管道的数目很大，而是支持更高级的属性，例如，延迟或取消消息传递的能力。 Cloud Tasks属于此类别，尽管Cloud Pub / Sub还采用了使其在该用例中越来越可行的功能。
因此Cloud Pub / Sub是SQS + SNS的发布/订阅方面，其中SNS用作将消息分发到不同的SQS队列的一种方式。它也可以作为大数据摄取机制。 Firebase Cloud Messaging涵盖了旨在访问最终用户设备的SNS部分。 Cloud Tasks（以及越来越多的Cloud Pub / Sub）提供了SQS中单个队列的功能。
,您正确地说GCP PubSub接近AWS SQS。据我所知，GCP中没有确切的SNS工具，但我认为最接近的工具是GCM（Google云消息传递）。您不是唯一拥有此查询的人： AWS SNS equivalent in GCP stack