查看: 52|回复: 0

即时通信服务器架构的一些思考

[复制链接]

该用户从未签到

发表于 2019-11-3 14:51:29 | 显示全部楼层 |阅读模式
对于一个即时通信服务器来说,在用户量少的时候,一台服务器就足以提供所有的服务。而这种架构也最简单,举个例子,用户A与用户B互为挚友,A向B发消息,服务器吸收到消息时,分析出吸收消息的人,直接转发给B即可。可是当用户数量越来越多时,一台服务器已经无法所有效户的需求,这时就要进行服务扩容,进行分布式部署
                        
                 
如图所示,差别的用户可能登录到差别的服务器上,那么用户A给用户B发消息时,服务器收到消息,首先判断B是否也登录在本服务器上,假如是,那么直接转发消息即可。假如B不在本服务器上,那应该往哪里转发这条消息呢?最简单的做法就是向服务器集群中的其他服务器广播这条消息,对于每个收到这条消息的服务器,首先判断消息的目的用户是否登录在本身身上,假如不是,直接忽略该消息。假如是,那么向目的用户转发该消息。固然,这种暴力粗犷的做法是最简单直接的,但是会产生很多无效的消息转发,对于服务器性能产生很大的影响。曾看过蘑菇街开源的即时通信软件Teamtalk的代码,服务器就是这种实现方式。其服务器架构如下:
                                   

                                             
差别的msg服务器连接到同一台route server上,所有msg服务器之间的转发全部通过route server。这无疑会加重route server的负载。即时msg server部署的再多,根据木桶理论,一个体系的性能是由其最薄弱的环节所决定的。以是也注定这样的架构,其体系容量也是有限的。那么如何改善这种体系呢,很明显服务器之间的消息转发不能直接全部广播,而应该有一套明确的路由体系,即服务器在转发消息时,应该知道这条消息应该转发到哪一台服务器,这样就不必要每条消息都在所有服务器之间广播了。
那么如何实现这样一套路由体系呢?
简单的做法是,每个用户上线时,通过其连接的msg server向其他所有msg server广播本身的登录信息,告知其他服务器本身登录在哪台服务器上面。这样当某个用户向其挚友发消息时,首先通过挚友id查看其登录的msg server。假如挚友与本身是同一台服务器,那么直接转发即可;假如不是,服务器向route server发送转发该消息,而且带上目标msg server的id.这样route server 收到消息后,分析出目标的msg server,进行一次转发即可,省去了大量的广播消息。这种方式固然办理了广播消息的问题,但是在每台msg server上都要保存所有效户的路由信息。当所有效户都登录时,几乎就退化成了单点模型,msg server肯定蒙受不了。
那么如何办理这个问题呢?试想一下,既然所有的msg server上都保存着同样的路由信息,那么我们可以把这些数据从msg server剥离出来,存在一个单独的服务器上,供msg server查询。我们暂且把这个服务器叫做route info server(路由信息服务器).对于一个用户要存储的数据为
{
   userid,
   msgserverid
}
假设这两个数据都是32Byte,那么存储一亿个用户必要的内存32B*10^8=3.2G。目前好点的服务器都有50G的内存,很显然内存不是问题。那么就剩访问量的问题。假如所有的msg server都从这一台服务器上读取数据, 肯定会影响整个体系的性能。以是路由信息服务器不能接纳这种单点模型。思量到这种路由信息的特点,很明显是一种读多写少的数据。一个用户只有在登录的时候才会写一次路由信息,其他时候就是转发消息的时候读取路由信息了。那么可以接纳类似数据库的主备模型,主服务器用来写路由信息,备服务器用于查询路由信息。而且可以设置多台备服务器,分担msg server的读压力。其实我们也可以使用一些成熟的缓存体系来完成路由信息服务器的功能,比如redis. redis拥有现成的主备方案,只是像这种通用的缓存服务器在存储数据时,斲丧的内存会大些。研究过redis源码的,大多都能理解。其key value都存储在redisobject的结构体当中,有一些附加的信息,以是比本身写一个这样的服务所斲丧的内存肯定会大些。
OK,说完了路由信息服务器,我们再回到msg server上来。那么msg server在转发消息时,首先根据目的用户的id 到路由信息服务器上查找其所在的msg server用于消息转发。但是这也会存在一个,每次转发消息时,都要查询一次路由信息,这无疑会影响消息的转发速度,而且也会增大路由信息服务器的访问压力。假如在发送消息之后,将路由信息保存到本地,那么下次发送消息,就无需再去路由信息服务器重复查询了。但是也不能把所有的路由全部保存到本地,那样又会严重斲丧msg server的内存。于是,就有我们想到一种折中的方案,使用一个lru的缓存队列,在必要保存新的路由信息时,首先查看缓存队列是否已满,假如未满,直接插入到队首,假如队列已满,镌汰到队尾的数据。缓存列队大小可根据内存大小机动设置。思量到在我们平时在使用QQ时,大部分人都登录着,但是发消息的人并不多。对于路由信息,在其首次转发消息是,从路由信息服务器查询一次路由,在其整个回话过程中,路由信息都缓存在本地。在其会话结束后,将近来最久未使用的路由数据镌汰出去,这种做法再思量到内存使用的同时,又大大淘汰了服务器的访问次数,算是一种较好的折中方案. 在完成了路由信息体系之后,route server也可以进行水平扩展,route server要做的仅仅是转发消息,并不必要存储数据,扩展起来非常方便。最终的体系架构如下:

                           

总结:
1. 本文所形貌的即时通信服务器架构,着重讨论的是消息如何路由的问题,但这并不代表一个完备的即时通信服务器体系,诸如注册,登录,离线消息,文件等功能这些都未在本文的讨论范围之类
2. 本文中所提的方案也是一种设想,并未真正进行实现,肯定也有很多细节问题没有思量到。接待大家留言讨论
3. 对于本文所提的体系,可称之为一个服务集群。而像qq这样数量用户的体系,在天下分布了很多个集群。本文所讨论的也仅仅局限于一个集群内的通信设计,而集群之间的通信又如何通信呢。每个集群的路由数据,假如全同步到其他集群,这种做法显然不是最优。假如有更好的想法,也接待留言讨论

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?用户注册

x

相关技术服务需求,请联系管理员和客服QQ:2753533861或QQ:619920289
您需要登录后才可以回帖 登录 | 用户注册

本版积分规则

帖子推荐:
客服咨询

QQ:2753533861

服务时间 9:00-22:00

快速回复 返回顶部 返回列表