我正在尝试设计一个实时群聊应用程序,专门针对每个聊天室中的大群组(>50个用户)。并不是所有的用户都会立即积极地聊天,但可以期待的是,当聊天进入聊天室时,许多用户会只是闲置/收听和接收更新。
我已经设计出了一个原型,它不是面向云的,并且正在重新设计基于云的系统。
我希望有一个‘重定向/负载平衡’服务器(LBServer),重定向到一系列的后端‘聊天’服务器(CServers)。当用户从客户端请求加入特定聊天室时,客户端将连接到LBServer,并且LBServer将用在存储器中维护聊天室实例的特定CServer的连接信息进行回复。然后,客户端将断开与LBServer的连接,并连接到CServer。只要用户仍在聊天室中,这种到CServer的连接就会一直存在。CServer负责更新记录聊天室状态的后端数据库,并将聊天室中的更新通知给连接到它自己的其他客户端。
你已经可以想象,如果一个聊天室中存在太多的用户(所以一个CServer必须保持与所有这些用户的持久连接),如果聊天室中的活动超过了服务器处理速度的阈值以跟上所有的更新,那么就会出现“热点”的情况。
在这一点上,我想出了一个简单的解决方案,这样我的系统仍然是可伸缩的。我可以加载一个更大的CServer实例,复制聊天室的状态,并请求“热”CServer中的所有用户重新连接到新的更大的实例。我不认为这是处理这种系统可伸缩性的正确方法。
我有几个问题:
考虑到我希望聊天的实时性,有没有一种更合适的方法来设计我的后端系统,以避免不得不将连接保持到一个服务器实例?
当我已经在数据库中跟踪状态时,我甚至需要费心将每个聊天室的处理都隔离在一个CServer上吗?我希望为用户留出空间,以便能够同时参与多个聊天室。如果我们使用我当前的模型,客户端将必须维护到我的云的多个连接(用户所在的每个聊天室一个)。这对客户端来说很糟糕。作为修订,我设想客户端将保持与“通用”CServers的连接,它将监听用户当前所在聊天室的变化,并相应地更新它们。
所有的反馈和意见都将非常感谢,我很乐意详细说明任何不清楚的地方。谢谢。
发布于 2011-05-26 02:13:25
我认为这里有几个设计方面的考虑:
James McGovern HP
发布于 2011-06-01 05:06:05
你可能想看看IRC http://en.wikipedia.org/wiki/Internet_Relay_Chat是如何做简单的多播的。IRC显然有一些可伸缩性问题和设计问题,但通常仍然工作得很好。IRC协议的两个问题是: 1)网络对服务器树有相当大的信任;2)网络状态的改变需要客户端的拆分/加入。有关RFC和其它技术问题,请参阅:http://www.irc.org/techie.html
这种比较http://en.wikipedia.org/wiki/Comparison_of_instant_messaging_protocols还包括PSYC ( SYnchronous会议协议-我从来没有听说过),据说已经解决了IRC协议的一些问题:http://about.psyc.eu/Introduction
也有XMPP http://fi.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol,但它不做多播,可能更适合MSN/Google Talk类型的一对一聊天,尽管FB chat (用Erlang编写)除了Google Talk之外还使用它。
说到Erlang http://en.wikipedia.org/wiki/Erlang_(programming_language -它遵循并发的Actor模型http://en.wikipedia.org/wiki/Actor_model,这有助于实现可分布性和可伸缩性。其他语言,如Scala、Common Lisp、Python和Haskell也支持Actor模型,无论是本机还是通过库。
PS。我并不自称是设计聊天协议的专家,只是碰巧对网络协议略知一二,最近做了一些关于并发编程技术的业余研究……
发布于 2011-06-07 22:20:34
我认为你可以利用一些MOM主题和订阅者模型。
https://stackoverflow.com/questions/6092437
复制相似问题