如何扩展 gRPC 发布/订阅聊天服务？

Question

我正在研究如何与GRPC进行聊天服务。我注意到大多数示例将所有订户的连接存储在列表数据结构中。当聊天室收到一条新消息时，服务器将循环浏览该列表并发送新消息。

将订阅者存储在源代码的变量订户。

我的问题是，当订户编号长大并将所有订户存储在哈希图中似乎是一个坏主意，因为这会花费太多的内存？我试图将这些连接存储在redis中，但是可能不可能由于连接无法序列化。

我的想法是当我在Kubernetes中部署多个POD实例时。每个聊天服务都变得独立。当订户分发在不同的服务器上时，我该如何正确获取订户？

Answer 1

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

• 任何聊天系统在聊天室大小方面都有一些限制。您想支持多少订阅者？如果您想支持数十（甚至数百）个订阅者，我相信它可以很好地处理内存中的订阅者列表，因为它比将订阅者列表存储在外部缓存中要快得多

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