IM系统用户离线上线问题解决方案

53 阅读 0 评论 35 点赞

我是靠谱客的博主缓慢便当，最近开发中收集的这篇文章主要介绍IM系统用户离线上线问题解决方案，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

(*如有转载,请注明出处及作者JeffNi)

IM系统用户离线上线问题解决方案

在架构IM软件也就是实时聊天软件的时候,通常会遇到一个用户离线上线的问题.初看上去这是个小问题,无非上线就通知服务器,然后再通知好友.下线也亦然.问题就真的这么简单吗?想想总理说过的一句话,任何小问题乘上中国13亿人口的基数,就会变成一个大问题.对了,问题就出在儿,当系统只有很少的在线用户(几百,几千,或者几万)的时候,这种设计没有

任何问题.但如果在线用户达到几百万,几千万用户呢,这中间会出什么问题.

首先是内存.暂时以一百万用户同时在线计算,至少须要保存用户ID,IP,PORT,Name,以及好友列表(ID+Name(10B)+Online)(Online表示在线还是离线一个字节).以平均每个人有100个好友计算.一个用户就至少需要1510B.共就是1510M的内存.噢...连普通PC都是1~2G的内存了,何况服务器呢.内存似乎不在是问题了.

然后是计算能力.最复杂的就是加入新用户(上线),查找好友了.用最常见的msvc hash_map保存这100万个用户,据在下在一台破电脑(AMD 1.8G 单核CPU,512M内存)上测试,插入一百万次是0.4649秒,而在这个长为100万的map里查询100万次的时候只有0.02143秒.我的神呀,这个也不是问题了.而如果用stl map时间就会要长一点,插入时间是0.8秒,查询时间就是
0.024秒.使用的VS2003编译,map类型map<unsinged long ,unsinged long>和hash_map<unsinged long ,unsinged long>.QueryPerformanceFrequency函数检测时间.

其次是带宽.现在的情况是,同时保持100万人在线,但单位时间内同时会有1万人上线,或者1万人离线.一个用户上线服务器需要做些什么呢,就是用户验证,发送好友列表及状态.每个好友的信息都是(ID+Name(10B)+Online)组成,那就是15个字节,100个用户就是1500,再加上协议头占的20字节(粗略估计)就是1520,另外还要发100个包告诉好友你在线了1520B.如果有一万人同时在登陆服务,就是15,200,000*2(30M).离线的时候,服务器需要向100个好友广播自己离线,1520*10000(15M).另外以最省事的UDP协议做,还是一个心跳占的带宽.100万人每三十秒一个20字节的心跳,平均带宽就是666KBS的带宽.总共就是45.666M的带宽.这也不算是大问题了.当然,这只是非常基础的流量统计,另外还有一些流量,能想到的就是文字聊

从政治上,用户体验上这一块都应该是服务器中转,而不要考虑P2P了(额的那个神呀,IM也有政治).最后,单台服务器的可靠性.很显然了,可靠性堪忧.服务器决定着整个网络的命运.也就是要么一起生,要么就一起死.(你的商业客户如果最初就看到这一条限制,估计早就走人,他可不愿意和你一起死)

综上所述,采用单台服务器的模式从性能上来说,在小于100百万人的系统上应用,基本没有什么重要的瓶颈(当然前提是你的老板或者买家接受一起生一起死).当然用户规模达到QQ样的级别同时在线2000万的级的时候以及的几乎所有数据都有翻20倍,几乎可以肯定单台服务器模式,在技术上和硬件上实现难度超大.商业上就更不用说了.因此,设计这样一个系统的时候,首先考虑的是可靠性,成本和技术那就是之后的平衡过程了.
有鉴于此,再此写一个IM的大体架构.首先,系统分为登陆服务器LoginServer(LS),状态服务器StatusServer(SS),以及其它业务服务器(聊天服务器ChatServer(CS),打洞服务器NATServer(NS),信令中转服务器(MS)等),这其中,每个所谓的服务器都以单独的进程呈现,有利于分工合作,排除相互之的干挠,利于后期调试快速错误定位到人头,营运的时候如果某个进程死掉了,或者出了问题,就只需要重启这一个进程,顶多影响到正在使用所属业务的用户,而不会影响到其它没有使用该业务的用户.

流程大致分为,客户(CC)去LS验证,获取到一个通行证PassPort(PP)(今后的某些关键通讯可以使用PP进行加密,并且是向其它服务器证明你是经过验证的用户的唯一凭证)以及SS的地址,之后中断与LS的连接,连接到SS.告之SS"我"上线了(这个连接至到退出系统都保持).这时SS从数据库或者缓存中提取出SS的好友信息,并将该信息发送给CC,以及把CC的信息发送
给在线好友.很明显SS在内存保存有所有用户的状态信息.只有当内存没有的时候,才从数据库中读取.这儿的SS应该做成多个,每个SS都保存所有用户的信息(必竟内存和查找速度不是瓶颈,性能和带宽才是关键和瓶颈),每CC通过LS负动态分配一个SS.并只与一个SS始终保持连接.SS之间要通过TCP协议进行用户状态信息交换.与其它服务器的连接及过程,就不叙述了,都比较简单的了.

这只是IM系统的一个比较粗糙的框架,还剩下很细节上的东西都没说出来.不过还好,其它东西基本都可以从这个或者那个项目提取出来直接使用了.此文希望对做IM系统的朋友有所帮助.