• 一个支持40万并发用户的即时通讯架构介绍


    前言:

    看了些讨论类似QQ的系统的文章,自己以前参与的一个项目,就做这个,不过规模相对小点。写份文档,旨在清理清理思路,交流一下经验。这里的一些模块名称(ACS、NAS),采用了以前公司的命名方式,我觉得这么用不当,觉得没有必要令换个名字。文中的内容与那个系统也有很大的区别,时间太长了,很多东西记不清了是一个原因,再者一直觉得那东西问题多多,做了些更改,同时为简单起见,去掉了很多的细节内容。准确地说这里描述的系统应该是一个杜撰出来的,因此我想不涉及什么商业秘密。

     

    一、摘要

    这个系统就支持用户的能力,我觉得完全可以支持像QQ那样的用户规模,不过个人觉得要是那么大的用户规模的话要做不少的优化处理。我接手做这东西的时候,支持三十万左右的并发在线就会宕掉。经过我的一番修理基本可以稳定支持到40万用户。感觉这个系统设计的也还行吧。大致结构如下

    二、整个系统的逻辑视图

     

    一个即时通信系统架构实现的讨论

     

    各模块的说明:

    C-XX:用户端使用自己定义的协议与NAS、ACS进行通信,提供IM的基本功能。
    NAS:为用户C-XX分配ACS服务器,在用户登录时进行。NAS简单的采用轮转的方式,依次分配系统中存在的ACS给登陆的用户。
    ACS:为用户提供IM服务端功能,主要有用户信息的修改,用户状态的维护,用户消息的处理等。ACS之间的逻辑结构是网状的,任何两个ACS都可以平等的进行通信。
    DB:保存用户的状态,不同的DB分成不同的区,维护不同段的用户。每个ACS到各个分区的数据库都有连接,ACS根据用户所在的区,访问相应的数据库,存取用户的数据。

    C-XX、NAS、DB-X的具体内容在这里不做太多的讨论,主要描述一下ACS的具体结构,主要的模块如下

     

    三、ACS的主要逻辑模块

    一个即时通信系统架构实现的讨论

     

    ACS中各个逻辑单元之间的描述:
    UserAgentsManager:管理用户相应的Agent,登录到服务器的所有UserAgent由其进行维护。
    UserAgent:用户的代理,提供用户功能的服务器侧实现。主要包括根据用户的操作,修改相应的数据库信息,维护用户状态,更新数据库中的用户状态和定位信息,包含用户的好友列表(Friends)维护用户的在线好友,根据用户的要求提供不同用户之间的通讯功能。
    ServerManagerModule:收集服务器的性能信息,维护日志信息和配置信息等。
    CommunicateWithOtherAcs:提供到其他ACS的通信服务功能。维护配置数据库中自身的状态,并从配置数据库中同步系统中其他ACS服务器的状态。
    UserLocatorInfoCache:对于用户的定位信息,要在向指定的用户发送数据包的时候频繁使用到,为减少这种数据库的访问操作给服务器带来很大的压力,对这种信息进行缓存,减少对数据库的压力。
    DatebaseAccessModule:提供数据库的访问接口。区分用户所在的段,到相应的数据库,存取用户的数据。

    用户定位信息:包括用户ID,登录的ACS编号,用户登录使用的IP地址,用户登录使用的端口(Port),用户使用的网络类型。这些信息是实现用户间的通信必需的,这些信息的维护和获取是系统中一个核心任务,相关操作十分频繁。

     

    四、物理部署视图

    一个即时通信系统架构实现的讨论

     

    说明:NAS为避免单点实效性,可以采用DNS或者NAT的方式,在多台服务器之间进行负载平衡。

     

    五、主要流程

    5.1 登录处理

    一个即时通信系统架构实现的讨论

     

     

    简单描述:用户的登录时,要将所有的在线好友的状态从数据库中取出,通知所有的好友用户登录事件,同时更新自己在数据库中的信息。以后用户数据包的转发,基本上是在好友之间的,保存好友的信息可以大量的减少对数据库的访问。

     

    5.2 ACS转发用户的中转消息的处理

    一个即时通信系统架构实现的讨论

     

    简单描述:在向指定的用户发送信息的时候,需要用户的定位信息,这些信息依次在好友列表,本地缓存和数据库之中进行查询。实际测试发现,使用本地缓存可以大大减少对数据库的访问。

     

    5.3 通过ACS转发消息

    一个即时通信系统架构实现的讨论

     

    简单描述:对于一些比较特殊的网络类型,如果需要保证数据包抵达指定用户,最稳妥的方式就是通过目的用户登录的ACS进行中转。在上图中User-01登录到ACS-01,User-02登录到ACS-02。

     

    后记

    一、支持更大规模应用的考虑

    我不维护这个系统的时候,系统可以支持40万左右。当时的感觉系统并没有达到支持的上限,感觉可以支持到100万左右。对于系统的近一步扩大,觉得系统还有宽展的潜力,支持更大规模的应用不是什么问题。可以在以下方式进行扩展:

    1、根据用户的使用习惯,细分分区,减少单个数据库的压力。服务器对于分区的变化能够给与相应的支持。
    2、对于用户登录的ACS的分配,使用复杂的策略,可以区分用户,使用不同的ACS。对于系统压力分布的可以方便的调整。
    3、感觉通过提高系统的配置性,可以实现不停的通过简单堆叠扩展系统容量,使系统随用户数量增加不断扩大。


     

    二、和以前看过的一些系统的对照

    后来感觉这个系统和GSM系统有些相似的地方,像保存用户信息和用户状态的数据库有点类似HLR的功用,对于ACS则有点像SMC,用户可以在各个ACS登录,登录到ACS后用户数据库中的用户状态要进行更新,以示其他用户和这个用户进行通信。对于NAS和ACS集群,很像个基于DNS的负载均衡系统。也许真的是万法归综…

  • 相关阅读:
    最有价值的专家--微软官方网站
    CC++初学者编程教程(16) 搭建Xcode cocos2dx开发环境--尹成老师博客
    微软最具价值的专家之毛星云博客
    Winsock IO模型之IOCP模型
    IOCP模型与网络编程
    关于proc索引的创建
    查找表存在于那些proc中
    Sql 时间做条件
    Sql 无指定条件,防并发update
    sql 根据客户需用 增减查询字段
  • 原文地址:https://www.cnblogs.com/hzcya1995/p/13318659.html
Copyright © 2020-2023  润新知