即时通信服务架构.docxVIP

即时通信服务架构 2021-12-12 对于一个即时通信服务器来说，在用户量少的时候，一台服务器就足以供应全部的服务。而这种架构也最简约，举个例子，用户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用于消息转发。但是这也会存在一个，每次转发消息时，都要查询一次路由信息，这无疑会影响消息的转发速度，而且也会增大路由信息服务器的访问压力。假如