对于一个即时通信服务器来说在用户量少的时候一台服务器就足以提供所有的服务。而这种架构也最简单举个例子用户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^83.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. 本文中所提的方案也是一种设想并未真正进行实现肯定也有很多细节问题没有考虑到。欢迎大家留言讨论