我正在开发一个可以在用户之间聊天的应用程序。为此使用Pub / Sub是否有意义？我在文档中找不到可能的用例。有什么很好的理由说明它不合适吗？
答案 0 :(得分：3)
Google Cloud Pub / Sub不太适合与聊天产品中的最终用户设备进行通信。 Cloud Pub / Sub专为种子设计：相对少量的需要高吞吐量的长寿命流。在聊天应用程序中，您需要细流：大量的临时流，它们的吞吐量很低。
Cloud Pub / Sub quotas仅允许10,000个主题项目，每个主题或每个项目10,000个订阅。设置新的流媒体管道时，通常会在开始时创建一次主题及其订阅，然后从该点开始发布和订阅。因此，通常与Dataflow和/或BigQuery结合使用，Cloud Pub / Sub更适合服务器到服务器的通信或大规模流事件摄取。
Cloud Pub / Sub的权限模型也不是聊天应用程序的理想选择。允许写入或读取主题或订阅的权限要求对用户进行身份验证。使用项目中的权限对每个用户进行身份验证实际上是不可行的，因此您可以选择为所有用户使用通用凭据，这可能是不安全的。
这并不是说Cloud Pub / Sub不能成为聊天服务的一部分，只是不能用于向特定用户传递消息。实际上，对于发送到环聊聊天机器人的消息，Cloud Pub / Sub可以为used as the transport mechanism。不过，在这种情况下，对用户的响应将直接转到环聊聊天API，而不是通过发布/订阅返回。因此，如果您正在实施聊天服务，则可能使您的用户将消息发送到您设计的前端服务器，然后将这些消息发布到Cloud Pub / Sub。您构建的另一台服务器可以是这些消息的订阅者，然后将适当的消息传递给适当的单个用户。在这种情况下，Cloud Pub / Sub用于接收来自前端服务器的所有消息（激流），而将消息传递给单个用户则属于某种其他机制（tri俩）。 Google Cloud中为此单个设备交付而设计的产品是Firebase Cloud Messaging，
答案 1 :(得分：1)
可以将Google Pub / Sub用于聊天消息吗？
是的。我不会使用发布/订阅进行人对人chat消息传递。 Pub / Sub设计用于使系统解耦以支持分布式系统。
为什么不使用发布/订阅：
poll订阅。这意味着每个聊天人员一个订阅。这既不是一个好的设计，也不是inexpensive。 chat有更好的解决方案。
答案 2 :(得分：0)
提供聊天的Sub / Sub？否。正如上面正确提到的那样，Pub / sub有2个主要用例，用于数据提取和系统解耦。
如果仍然有兴趣制作聊天应用，我建议您搜索一些有关Web套接字的信息。