如何扩大gRPC发布/子聊天服务？

Question

我正在学习如何与gRPC建立聊天服务。我注意到，大多数示例都将订阅者的所有连接存储到一个列表数据结构中。当聊天室收到新消息时，服务器将循环浏览该列表并发送新消息。

将订阅者存储在源代码的可变订阅者中。

我的问题是，当订阅者数量增加并将所有订阅者存储在HashMap中似乎是个坏主意，因为这会消耗太多内存？我尝试将这些连接存储在Redis中，但由于连接不可序列化，这可能是不可能的。

我的想法是在Kubernetes中部署多个pod实例。每个聊天服务都变得独立。当订阅者分布在不同的服务器上时，我如何才能正确地获取它们？

Answer 1

以下是我思考的几个方面：

• 任何聊天系统都有聊天室大小的限制。你想支持多少订户？如果你想支持数十（甚至数百）个订阅者，我相信它可以很好地与内存中的订阅者列表配合使用，因为它比将订阅者列表放入外部缓存要快得多

• 当您需要向整个订阅者列表发送消息时，您可以使用IO优化的线程池并行执行，而不是在该列表上循环。
• 在pod中部署聊天服务是个好主意，您需要能够横向扩展，但您还需要在服务前面有一个智能网关，将来自给定用户的请求路由到存储其信息的pod（如果订阅者列表存储在内存中）。否则，如果此信息存储在外部（缓存中），您的聊天服务可能完全无状态。