浅谈个人对IM服务端设计与实现的一点理解

本文将简略描述一下在大用户量跨域访问的IM（即时通讯软件）服务端的设计和实现中需要考虑的一些技术点、难点,以及个人对其架构和实现的一点构思

背景：最近纯处于练手的目的,打算个人实现一个简单的即时通讯程序,着重于服务端模块；为做测试之用,即使是简陋的客户端也是的,然苦于缺乏windows下界面编程能力,故计划中将使用ExtJS配合websocket实现简单的web客户端

从设计之初即考虑大用户量 情况下的解决办法；服务端以Linux为平台,C为主要开发语言；本为将据进度持续更新,都是下班后休息时弄,预计进度将不是很快

在大量用户的前提下,与一般企业使用的局域网即时通讯工具将有很多不同的地方,需要考虑的地方更多,以下简要罗列：

1.多用户高并发的处理：支撑同时在线人数的数量,不得不考虑,不然qq是不能存活如此之久；不能仅仅靠机器扩容来解决问题,即使可以如此,也要考虑模块是否支持扩容；更好的思路是在支持扩容的前提下,设计更好的请求处理模型,比如异步方式

2.p2p对等通信的处理：局域网或许更容易处理p2p通信；IM中常见的有C/S,C/S与P2P结合的多种方式,在文件传输中更迫切的需要使用P2P的方式,目前个人感觉目录集中式结构的伪P2P最易于实现,更实际；在文件传输中,不同于局域网,涉及到跨域问题,还需要考虑NAT穿透等技术

3.通信协议的设计：C-S , C-C,S-S之间有多种通信,消息传递,文件传输请求,状态更改请求,状态信息推送,登入登出,系统通知,类型多种多样,目前也有几种流行的协议模型,二进制协议,基于xml的等等,我目前选择二进制协议

4.IM是繁忙的,对数据库请求的压力很大,用户信息都需要在服务端cache,实现在线期间的信息持久化,需要设计好的cache管理方式；

5.多点登录的处理

6.C-S之间是需要维持长连接的,长连接的维持如何处理；IM是有状态的服务

7.优化层面,用户信息结构、连接信息结构的生成、销毁,频繁的内存请求导致的压力促使我们考虑内存分配的管理,例如内存池

额,越说越往实际的细节上说了,其实还有很多宏观的方面,例如各模块之间复杂的关联,开始语无伦次了,符合我一贯的风格；既然说到细节了,那就继续吧

下面是目前对整体的模型的一个思考：

客户端和服务端之间需要保持长连接,当在线用户量极大的时候,对系统的压力是很大的,众多连接的维护管理本身就是个难题；如果没有良好的逻辑划分,结果就是系统无法承受多用户的压力,如果一个模块维持如此众多的连接并进行各种请求的处理,结果可想而知

,要进行划分：

用户直连的,是接入模块,暂命名为access；access只负责用户的接入,用户在线期间和客户端保持长连接,做一些简单的防护措施,以后会增加其他的协商功能等等；

第二个模块暂时被我命名为logic,这个模块针对每个用户的每个请求进行逻辑的判断,确定请求的类型,但并不做实际处理,只是将请求转发到相应的功能模块做实际处理,这个映射logic模块自己知道；,logic会做第一层的解包操作,然后进行分工

access和logic之间也是长连接,都是针对每个用户都有个长连接；,两个长连接之间的衔接要做好

access和logic都要保持数量庞大的连接,logic模块的逻辑比access更多,需要上连access,下联众多功能模块；logic的逻辑更多,access与logic应该是一对多的关系,access接入之后可能将连接转接到不同的logic机器上

access和logic均使用的是多线程以及epoll来进行连接的管理：监听线程负责accpt,然后通过信号的方式给其中一个线程通知新连接的到来；每个epoll线程会有一个epoll实例（系统会初始化一定数量的epoll线程）,每个epoll实例可管理较大量的连接

logic对用户的管理：之前已经说过,每个用户的一个在线时间

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!