cloud - 设计后端(云)服务器以避免 'hotspot' 场景

Question

我正在尝试设计一个实时群聊应用程序，专门针对每个聊天室中的大型群组(> 50 个用户)。并非所有用户都会立即积极聊天，但可以预期许多用户只是闲置/收听并在聊天进入聊天室时接收更新。

我已经制定了一个不面向云的原型(prototype)，并且正在重新设计基于云的系统。

我希望有一个“重定向/负载平衡”服务器(LBServer)重定向到一系列后端“聊天”服务器(CServers)。当用户从客户端请求加入特定聊天室时，客户端将连接到 LBServer，LBServer 将回复特定 CServer 的连接信息，该 CServer 在内存中维护聊天室实例。然后客户端将与LBServer断开连接并连接到CServer。只要用户留在聊天室中，这种与 CServer 的连接就会持续存在。 CServer 负责更新记录聊天室状态的后端数据库，并将聊天室中的更新通知连接到自身的其他客户端。

您已经可以设想，如果一个聊天室中存在太多用户(因此一个 CServer 必须保持与所有这些用户的持久连接)，如果房间中的事件增加超过 CServer 处理速度的阈值，就会出现“热点”场景以保持与所有更新。

在这一点上，我想出了一个简单的解决方案，这样我的系统仍然是可扩展的。我可以加载一个更大的 CServer 实例，复制聊天室的状态，并请求“热”CServer 中的所有用户重新连接到新的更大实例。我不认为这是处理此类系统可扩展性的正确方法。

我有几个问题:

鉴于我希望聊天的实时性，是否有更合适的方法来设计我的后端系统以避免必须保持与一个服务器实例的连接？

当我已经在跟踪数据库中的状态时，我什至需要费心将每个聊天室的处理都隔离在一个 CServer 上吗？我想留出空间让用户能够同时参与多个聊天室。如果我们使用我当前的模型，客户端将不得不维护与我的云的多个连接(用户所在的每个聊天室一个连接)。这对客户端来说很糟糕。作为修订，我设想客户端保持与“通用”CServer 的连接，这些 CServer 将监听用户当前所在聊天室的变化并相应地更新它们。

非常感谢所有反馈和意见，我很乐意详细说明任何不清楚的地方。谢谢。

Answer 1

我认为这里有几个设计考虑:

考虑让每个聊天室在 DNS 中显示为子条目。例如，chatroom1.chatservice.com。这样，您可以跨服务器进行负载平衡并保持粘性。

聊天服务器可以通过多播相互通信，并且可以将消息的发送者与接收者解耦以提供规模。

您不需要维护持久连接，而是通信流需要包含一个可以处理路由职责的 token 。

詹姆斯·麦戈文
生命值