我正在尝试设计一个专门针对每个聊天室中的大型群组(> 50个用户)的实时群聊应用程序.并非所有用户都会立即进行主动聊天,但是当聊天进入聊天室时,人们可以期望许多用户只是闲置/收听和接收更新.
我已经制定了一个非面向云的原型,并且正在重新设计基于云的系统.
我希望有一个"重定向/负载平衡"服务器(LBServer)重定向到一系列后端"聊天"服务器(CServers).当用户请求加入来自客户端的特定聊天室,客户端将连接到LBServer和LBServer将与维护在内存中的聊天室的一个实例特定CServer的连接信息回复.然后客户端将断开与LBServer的连接并连接到CServer.只要用户留在聊天室中,就会保持与CServer的这种连接.CServer负责更新记录聊天室状态的后端数据库,并通知聊天室中与更新相关的其他客户端.
你已经可以设想如果有太多的用户在一个聊天室(这样一个CServer必须保持所有这些用户的持久连接)的存在,如果在室内活动增加过去的CServer的处理速度的门槛,以保持一个"热点"的场景将展开所有更新.
在这一点上,我提出了一个天真的解决方案,以便我的系统仍然可扩展.我可以加载一个更大的CServer实例,复制聊天室的状态,并请求"热"CServer中的所有用户重新连接到新的更大的实例.我不相信这是处理这种系统可扩展性的正确方法.
我有几个问题:
鉴于我希望聊天的实时性,有没有更合适的方法来设计我的后端系统,以避免必须持续连接到一个服务器实例？
当我在数据库中跟踪状态时,我是否还需要打扰隔离每个聊天室的处理以在一个CServer上发生？我想留出空间让用户能够同时参加多个聊天室.如果我们使用当前模型,客户端将必须维护与我的云的多个连接(用户所在的每个聊天室都有一个).这对客户端来说太糟糕了.作为修订,我设想客户保持与"通用"CServers的连接,这些CServers将监听用户当前所在的聊天室的变化并相应地更新它们.
所有的反馈和意见都将受到极大的赞赏,我很乐意详细说明任何不清楚的事情.谢谢.
我认为这里有几个设计考虑：
考虑让每个聊天室显示为 DNS 中的子条目。例如，chatroom1.chatservice.com。这样，您就可以跨服务器进行负载平衡并保持粘性。
聊天服务器可以通过多播相互通信，并且可以将消息发送者与接收者解耦以提供规模。
您不需要维护持久连接，但通信流需要包含可以处理路由职责的令牌。
詹姆斯·麦戈文 HP
| 归档时间： |
|
| 查看次数： |
501 次 |
| 最近记录： |