论文研究-基于发布订阅机制的即时通讯系统的设计与实现 .pdf

所需积分/C币:11 2019-08-27 19:48:32 320KB .PDF
收藏 收藏
举报

基于发布订阅机制的即时通讯系统的设计与实现,申民发,,随着即时通讯在手机应用中占据着越来越重要的地位,该功能已经成为手机应用不可或缺的一部分。传统的即时通讯系统的设计方案过于
山国利技论文在线 http://www.paper.edu.cn ∠ keeper服务器 通知集群节点变化 通知集群节点变化 通知集群节点变化 消息转发服务器 转发消息 转发消息 消息转发服务器 转发消息………(消息转发服务器 读取、存储数据 读、存储数据 读取、存储数据 ongoDB数据库 图1系统部署图 Fig 1 S ployment diagram 70 22系统模块设计 业务逻辑模块 业务层 离线消息模块 单聊群聊模块 发布订阅管理模块)(路由模块 M层 通信模块 图2系统模块图 Fig 2 System module diagram 系统按照模块功能整体可以划分为两层:业务层、ⅠM层。 其中IM层实现了整个即时通讯系统消息转发的底层通信部分,为上层提供封装好的、 简单的发送、接收消息的调用接口。 业务层主要提供与特定业务相关的接口,如用户身份的识别, Loken校验、黑名单管 理、好友关系校验、离线消息获取、消息的推送等。下面将详细讲解各个模块 23通信模块 80 通信模块负责与客户端或集群中其他服务器建立并保持连接。本系统在通信连接上使用 TCP协议,在通信的数据包格式上使用二进制的私有协议。私有协议的具体格式不再详述, 使用本方案设计的开发者可以使用仟何一和适合的数据格式,不影响整个方案的实现。通信 模块通过 ZooKeeper服务器与其他服务器建立连接,并在其他服务器宕机时将向发布订阅模 山国利技论文在线 http://www.paper.edu.cn 块提供宕机事件通知ε通信模块同吋也向发布订阅模块提供主题订阅发布的事件通知,向路 由模块提供其他服务器的消息转发事件。通信模块与客户端自动通过心朓包保持连接的活跃。 除以上功能外,通信模块向上提供向具体客户端或服务器发送消息的接口。 发布订阅管理馍块 路山模块 业务逻辑模块 主题创建、订阅、取消通知其他服务转发的消息客户端的消息 通信模块 图3通信模块功能图 Fig 3 Function diagram of communication module 24发布订阅管理模块 发布订阅管理模块要负责维护整个集群及本服务器上的主题映射关系,并为路山模块 提供路山查询服务。发布订阅管理模块内部有一张⊥题映射表,记录了所有的主题与客户端 和主题与集群中服务器节点之间的映射关系。 主题快射表 修改昏询 本机主题变更事件 发布订阅管理模块 路由模块 主题创建、订阅、取消通知 通信模块 95 图4发布订阅管理模块功能图 Fig 4 Function diagram of publish-subscribe management module 主题映射表是本系统中处于核心的一个数据结构,是整个发布订阅中主题映射关系的存 储结构。主题映射表使用LRU缓存队列实现,由发布订阅管理模块直接维护。主题映射 表中存储的映射关系的上限值在系统配置文件中设置,系统部署过程中可以根据当前在线用 户的规模进行对应修改。主趣映射表达到上限后会触发缓存删除机制,活跃状态最低的主题 将被删除。如果主题被删除后向主题中发布消息,将通过被动订阅的方式在主题映射表中重 建该主题。被动订阅木文以下部分讲解 2.5路由模块 路由模块在系统中主要提供消息在本机基于主题的分发、向集群中其他服务器转发消息、 105向上提供本机主题关系修改的接口。 路山模块在处理用户的发消息请求时,首先调用发布订阅管理模块提供的辶题路径査询 接口,获取所有主题对应的本机客户端以及服务器。对于本机的客户端,将直接进行推送工 作,对于其他服务器,将进行消息转发工作。 路由模块冉接收到其他服务器转发来的消息后,首先从中提取出消息的主题,之后调用 110 发布订阅管理模块的査询接口,获取木机订阅此主题的所有客户端,在将消息添加上相应用 广的标志后向上提供给业务层,再进行相应的业务逻辑。 4 山国利技论文在线 http://www.paper.edu.cn 本札主题变更是业务层好友关系改变、客户端上卜线引起主题时间,路由模块直接调用 发布订阅模块的相应的变更接口进行处理 单聊群聊模块 提供别人转发的消息发送消息、主题变更 发布订阅管理模)查询结果 路由模块 其他服务器转发的消息向其他服务器转发消息 通信模块 115 图4路由模块功能 Fig 4 Function diagram of routing module 2.6单聊群聊模块 该模块主要负贲将业务中单聊、群聊的概念转换成发布订阅机制中主题的概念。本系统 将群聊的I作为主题,单聊作为特殊的群聊来设计。同时该模块在接收到其他服务器发来 120 的消息后,如果用户已经下线,将走离线消息处理,即发送给离线模块 业务逻辑模块 单聊、群聊消息 寫线消息模块离线消总事件 单聊群聊模块 图5单聊群聊模块功能图 Fig 5 Function diagram of single and multiple chat module 2.7离线消息模块 125 离线模块负责存储离线消息,对业务层提供离线消息查询的接口。离线消息存储在 MongoDB数据库中,所以离线模块可以对 MongoDB进行存储和查询操作。 业务逻辑模块 离线消息查询 离线消息模块 离线消息查询、存储 ngo 图6离线模块功能图 Fig 6 Function diagram of offline module 山国利技论文在线 http://www.paper.edu.cn 130 28业务逻辑模块 业务逻辑模块负责业务层的逻辑处理,可以直接与通信模块进行交互数据。在获取离线 消息时,通过离线模块获取。在进行单聊、群聊时通过单聊群聊模块处理 务逻缉模块 聊天消息发送 客户端请求消息推送、请求响应 单聊群聊模块 通信模块 图7业务逻辑模块功能图 135 7 Function diagram of business logic mod 29主动订阅与被动订阅 发布订阅机制是基于主题来转发消息,当服务尜或客户端没有订阅某一主题时,系统将 不负责向其转发或推送该主题下的消总。所以在客户端刚上线或主题尚未建立时,需要通过 主动订阅和被动讠阅两种方式来初始化消息的转发环境。 140 291主动订阅 主动订阅发生在客户端刚连接系统,系统需要通过主动订阅的方式初始化该客户端用户 的聊天环境。 系统在客户端上线后,通过数据库获取该客户端上用户的所有群聊。通过系统的路由模 块提供的封装了发布订阅模块的检测接口,将该用户的所冇群聊进行检测。筛选出当前处于 l45 活跃状态的群聊。最后主动订阅这些群聊的主题,以此使系统将接下来这些群聊产生的消息 推送给自己。 292被动订阅 被动订阅发生在向某一未创建的主题中发布消息时,由于该主题没有被创建,所以没有 任何客户端或服务器订阅该主题,系统将无法转发该主题中的消息。 150 系统在遇到这种情况时,将首先在本机上创建该主题,并査阅本机上所有在该主题群聊 下的在线客户端,并强制这些客户端订阅该主题。同时向集群中其他服务器节点广播主题创 建事件,其他服务器节点在收到该事件后,同样将关于该主题群聊下的本机在线客户端强 订阅到该主题卜。通过这些步骤,此主题的整个订阅环境将被建立。整个过程完成后,如有 其他在该群聊主题中的客户端上线,将通过主动订阅的方式完成聊天环境初始化。 1553系统测试 3.1测试环境 3.1.1硬环境 测试的硬件坏境如表1所示。 表1硬件环境 160 Tab. 1 hardware environment 名称 操作系统 内存 CPU 6 山国利技论文在线 http://www.paper.edu.cn 云服务器 centos 7.0 80 四核 联想笔记本电脑 window 7 6G 四核 苹果笔记本电脑 macoS10.13.1 8G 双核 3.1.2软件环境 测试需要的软件坏境如表2所 表2软件环境 Tab 2 Software environment 名称 版木 JDK 1.8 y 4.1 1.8 PushDebug脚本 1.0 MongoDB数据库 3.4 docker 17.06. PushDebug脚本是为本系统测试单独开发的测试脚本,用来模拟大量用户同时使用系统 各种功能玚景。脚本运行过程自动收集指定的满足条件的数据,并与入日志文件。系统测试 结果将使用该数据进行分析。 313数据库准备 170 需婁在数据库中建立系统测试所需要的关键数据,按如下步骤进行: 1、使用脚本在 MongodB数据库中建立10000用户,用户的ID按照字符串 userid 加序号的规则创建,序号为0到9999 2、使用胭本在 MongoDB数据库中建立6000个聊天室,聊天室的按照字符串 roomed 加序号的规则创建,序号为0到5999 175 3、使用脚本为每个用户均匀分配30个聊天室。 32测试方案 3.21系统部署 1、在云服务器上启动单个 MongoDB实例,监听TP地址为0.0.0.0,端口号为27017 2、在云服务器上启动单个 Zookccpcr实例,监听IP地址为0.0.00,端口号为2181a 180 3、在云服务器上启动三个 docker实例,每个 docker实例中部老本即时通讯系统,即时 通讯系统配置文件中连接数据库的地址和 ZooKeeper的连接地址填写云服务器主机地址。 322测试步骤 1、启动云服务器上部署的系统 2、使用 PushDebug脚本开启100个用户,每个用户每隔1到5秒随机向自己的聊天室 185 之一发送一次消息。并在凵志文件中记求消息发送时间及服务器响应时间。运行1分钟,统 计日志数据,计算平均发送时间。 3、使用步骤2相同的处理方式,分别尝试开启的用户数量为500、1000、2000、4000、 7 山国利技论文在线 http://www.paper.edu.cn 8000、10000、20000、30000、40000、50000、60000、70000、80000、90000、100000。 33测试结果与分析 l90 以下是测试的结果截图与结果的分析。 play, GeneraTHandl userId: userId22cost:21 msgId;84307453611525331641512009991407290000 General Handler sENDMSG userId:use 33867137785077994011512009991419866000 INFO 2017-11-30 10: 46: 31, 262 comunisky play. GeneralHandler SENDMSG userId: userId42 cost: 16 msgId: 216179540840569061 1512009991419913000 图8消息发送日志截图 Fig. 8 Message sending log screenshot uce_topchouce_top_ pc /cygdrive/e/we_java/pushdebug cat run, log Igre head -n 10 NFo 2017-11-30 10: 46: 30, 225 comuniskyplay. GeneralHandler Conn userId: userId22 cost: 1512009990223 INFO 2017 5 com. uni sky. play. GeneralHandler Conn userId; userId9 cost: 1512009990224 NFO 2017-11-30 10: 46: 30, 225 com unisky play. GeneralHandler Conn userId: userId3 cost: 1512009990224 NFO 2017-11-30 10: 46: 30, 225 com unisky play. GeneralHandler: Conn userId: userId4 cost: 1512009990224 INFO 2017-11-30 10: 46: 30, 233 com unisky play. GeneralHandler Conn userId: userId7 cost: 15120099902 INFO 2017-11-30 10: 46: 30, 237 com. uni sky. play. GeneralHandler Conn userId: userIdll cost: 1512009990237 NFO 2017-11-30 10: 46: 30, 238 com unisky play. GeneralHandler Conn userId: userId1 cost: 1512009990238 NF02017-11-3010 0, 238 com.unisky play. GeneralHandler Conn userId; userId6 cost: 1512009990238 NFO 2017-11-30 10: 46: 30, 238 com. uni sky. play. GeneralHandler Conn userId: userIdo cost: 1512009990238 NFO 2017-11-30 10: 46: 30, 239 com unisky play. GeneralHandler Conn userId: userId15 cost: 1512009990238 195 图9连接建立日志图 Fig 9 Connection building log screenshot ouce-topChouce_top_pc/cygdrive/e/we_java/pushdebug s cat run. loglgrep "SENDMSG userId"lawk cost:" Print $2] awk 'sum + 51: END print sum/NR] 219,368 houce-topehouce_top_pc/cygdrive/e/we__java/pushdebug 图10平均发送时间计算结果 Fig. 10 Average transmission time calculation 9000 8000 7000 6000 三5000 4000 3000 2000 1000 0 020000400006000080000100000120000 同时在线用户数量(单位:个 200 图11服务器处理消息发送平均时间 Fig. 11 The average time of server processing message sending 图9为服务器处理客户端消息发送的平均时间。从图中可以看出,当在线用户量在1 到40时,消息的处理时间变化不大,在50毫秒附近。当在线用户量超过40000后,系 205 统处理消息发送的时间开始显增长。用户量在60000之前,消息平均处理时间都在1秒以 山国利技论文在线 http://www.paper.edu.cn 卜,理论上用户体验不到明显的廷迟。当用户量超过60000时,消息平均处理时间快速上丌。 这种情况下,系统的性能明显下降,用户将感觉到明显的延迟。 4结论 本文给出了通过发布订阅机制实现即时通讯系统的技术方案。该方案可以在现有的发布 210 订阅系统的基础上做二次开发。通过系统测试展示的数据可以得出该系统在用户規模不超过 6000的情况下能够高效地进行服务,适合拥有小规模在线用户的公司使用。 参考文献]( References [1] Wenbing Zhao. On the Quorum Requirement and Value Selection Rule for Fast Paxos[A]. IEEE Beijing 215 Section. Proceedings of 2014 Ieee Sth International Conference on Software Engineering and Service Science[C IEEE Beijing Section, 2014. 4 [2]朱先飞,陈淑珍,余文博.基 J SIMPLE和ⅹMPP协议的移动IM研究[广东通信技术,2011,31(12): 49-54 3」周士雄.基于ⅩMPP协议的移动平台即时通讯系统的设计与实现D」哈尔滨⊥业大学,2013. 220 [4]差仕军.基于XMPP协议的跨平台M系统的设计与实现[D].大连海事大学,2012. [5]陈昊,高楚舒,魏峻,叶丹.基于 Actor模型的高性能分布式ⅪMP服务器[J.计算机系统应用,2015, 24(10):62-67 9

...展开详情
试读 9P 论文研究-基于发布订阅机制的即时通讯系统的设计与实现 .pdf
立即下载 低至0.43元/次 身份认证VIP会员低至7折
    抢沙发
    一个资源只可评论一次,评论内容不能少于5个字
    img

    关注 私信 TA的资源

    上传资源赚积分,得勋章
    最新推荐
    论文研究-基于发布订阅机制的即时通讯系统的设计与实现 .pdf 11积分/C币 立即下载
    1/9
    论文研究-基于发布订阅机制的即时通讯系统的设计与实现 .pdf第1页
    论文研究-基于发布订阅机制的即时通讯系统的设计与实现 .pdf第2页
    论文研究-基于发布订阅机制的即时通讯系统的设计与实现 .pdf第3页

    试读已结束,剩余6页未读...

    11积分/C币 立即下载 >