专栏首页测试技术圈一个海量在线用户即时通讯系统(IM)的完整设计Plus

一个海量在线用户即时通讯系统(IM)的完整设计Plus

《一个海量在线用户即时通讯系统(IM)的完整设计》(以下称《完整设计》)这篇文章发出来之后有不少读者咨询问题,提出意见或建议。主要集中在模块拆分、协议、存储等方面。针对这些问题做个简单说明。

1、真实生产系统的模块拆分比《完整设计》一文中要复杂许多。《完整设计》只在反应IM系统最核心大功能点之间的关系,便于没有经验的读者能够快速上手进行IM设计和开发。真实运行系统的架构接近于这张图

2、消息存储部分,最初版本采用的MySQL,之后改成了HBase(用Cassandra也行)。按照会话进行了分区,单聊、群聊是分开存储的。

3、拉离线(消息同步模型)方式。针对内部员工采用的《完整设计》的拉取方式;针对C端用户采用了TimeLine模型。参看《基于TimeLine模型的消息同步机制》《TimeLine模型下确保消息有序不丢》

4、在协议、安全等很多方面都有改进

《完整设计》一文更适合没有太多完全自研IM经验的研发人员阅读,基本能够覆盖到IM自研的主要环节。以下附上《完整设计》原文

1 服务器端设计

1.1 总体架构

总体架构包括5个层级,具体内容如下图。

1.1.1 用户端

移动端重点是移动端,支持IOS/Android系统,包括IM App,嵌入消息功能的瓜子App,未来还可能接入客服系统。

1.1.2 用户端API

针对TCP协议,提供IOS/Android开发SDK。对于H5页面,提供WebSocket接口

1.1.3 接入层

接入层主要任务是保持海量用户连接(接入)、攻击防护、将海量连接整流成少量TCP连接与逻辑层通讯。

1.1.4 逻辑层

逻辑层负责IM系统各项功能的核心逻辑实现。包括单聊(c2c)、上报(c2s)、推送(s2c)、群聊(c2g)、离线消息、登录授权、组织机构树等等内容。

1.1.5 存储层

存储层负责缓存或存储IM系统相关数据,主要包括用户状态及路由(缓存),消息数据(MySQL也可采用NoSql,如MangoDB),文件数据(文件服务器)。

1.2 逻辑结构

1.2.1 核心结构

核心结构部分描述IM系统核心组件及其关系。结构图如下。

客户端从Iplist服务获取接入层IP地址(也可采用域名的方式解析得到接入层IP地址),建立与接入层的连接(可能为短连接),从而实现客户端与IM服务器的数据交互;业务线服务器可以通过服务器端API建立与IM服务器的联系,向客户端推送消息;客户端上报到业务服务器的消息,IM服务器会通过mq投递给业务服务器。

1.2.2 tcp接入核心流程

1.2.2.1 登录授权(auth)

1、客户端通过统一登录系统实现登录,得到token。

2、客户端用uid和token向msg-gate发起授权验证请求。

3、msg-gate同步调用msg-logic的验证接口

4、msg-logic请求sso系统验证token合法性

5、msg-gate得到登录结果后,设置session状态,并向客户端返回授权结果。

1.2.2.2 登出(logout)

1、客户端发起logout请求,msg-gate设置对应Peer为未登录状态。

2、 Msg-gate给客户端一个ack响应。

3、 Msg-gate通知msg-logic用户登出。

1.2.2.3 踢人(kickout)

用户请求授权时,可能在另一个设备(同类型设备)开着软件处于登录状态。这种情况需要系统将那个设备踢下线。

1-5步,参看Auth流程。

6、 Logic检索Redis,查看是否该用户在其他地方登录。

7、 如果在其他地方登录,发起kickout命令。(如果没有登录,整个流程结束)

8、 Gate向用户发起kickout请求,并在短时间内(确保客户端收到kickout数据)关闭socket连接。

1.2.2.4 上报(c2s)

1、 客户端向gate发送数据

2、 Gate回一个ack包,向客户端确认已经收到数据

3、 Gate将数据包传递给logic

4、 Logic根据数据投递目的地,选择对应的mq队列进行投递

5、 业务服务器得到数据

1.2.2.5 推送(s2c)

1、 业务线调用push数据接口sendMsg

2、 Logic向redis检索目标用户状态。如果目标用户不在线,丢弃数据(未来可根据业务场景定制化逻辑);如果用户在线,查询到用户连接的接入层gate

3、 Logic向用户所在的gate发送数据

4、 Gate向用户推送数据。(如果用户不在线,通知logic用户不在线)

5、 客户端收到数据后向gate发送ack反馈

6、 Gate将ack信息传递给logic层,用于其他可能的逻辑处理(如日志,确认送达等)

1.2.2.6 单对单聊天(c2c)

1、 App1向gate1发送信息(信息最终要发给App2)

2、 Gate1将信息投递给logic

3、 Logic收到信息后,将信息进行存储

4、 存储成功后,logic向gate1发送ack

5、 Gate1将ack信息发给App1

6、 Logic检索redis,查找App2状态。如果App2未登录,流程结束

7、 如果App2登录到了gate2,logic将消息发往gate2

8、 Gate2将消息发给App2(如果发现App2不在线,丢弃消息即可,这种概率极低,后续离线消息可保证消息不丢)

9、 App2向gate2发送ack

10、Gate2将ack信息发给logic

11、Logic将消息状态设置为已送达。

注:在第6步和第7步之间,启动计时器(DelayedQueue或哈希环,时间如5秒),计时器时间到后,探测该条消息状态,如果消息未送达,考虑通过APNS、米推、个推进行推送

1.2.2.7 群聊(c2g)

采用扩散写(而非扩散读)的方式。

群聊是多人社交的基本诉求,一个群友在群内发了一条消息:

(1)在线的群友能第一时间收到消息

(2)离线的群友能在登陆后收到消息

由于“消息风暴扩散系数”的存在,群消息的复杂度要远高于单对单消息。

群基础表:用来描述一个群的基本信息

im_group_msgs(group_id, group_name,create_user, owner, announcement, create_time)

群成员表:用来描述一个群里有多少成员

im_group_users(group_id, user_id)

用户接收消息表:用来描述一个用户的所有收到群消息(与单对单消息表是同一个表)

im_message_recieve(msg_id,msg_from,msg_to, group_id,msg_seq, msg_content, send_time, msg_type, deliverd, cmd_id)

用户发送消息表:用来描述一个用户发送了哪些消息

im_message_send (msg_id,msg_from,msg_to, group_id,msg_seq, msg_content, send_time, msg_type, cmd_id)

业务场景举例:

(1)一个群中有x,A,B,C,D共5个成员,成员x发了一个消息

(2)成员A与B在线,期望实时收到消息

(3)成员C与D离线,期望未来拉取到离线消息

群聊流程如下图所示

1、X向gate发送信息(信息最终要发给这个群,A、B在线)

2、Gate将消息发给logic

3、存储消息到im_message_send表,按照msg_from水平分库

4、回ack

5、回ack

6、Logic检索数据库(需要使用缓存),获得群成员列表

7、存储每个用户的消息数据(用户视图),按照msg_to水平分库(并发、批量写入)。

8、查询用户在线状态及位置

9、Logic向gate投递消息

10、Gate向用户投递消息

11、App返回收到消息的ack信息

12、Gate向logic传递ack信息

13、向缓存(Hash)中更新收到ack的时间。然后在通过一个定时任务,每隔一定时间,将数据更新到数据库(注意只需要写入时间段内有变化的数据)。

1.2.2.8 拉取离线消息

下图中,将gate和logic合并为im-server。拉取离线消息流程如下。

1、 App端登录成功后(或业务触发拉取离线消息),向IM系统发起拉离线消息请求。传递3个主要参数,uid表明用户;msgid表明当前收到的最大消息id(如果没收到过消息,或拿不到最大消息id则msgid=0)即可;size表示每次拉取条数(这个值也可以由服务器端控制)。

2、 假设msgid==0,什么都不做。(参看第6步骤)

3、 Im-server查询用户前10条离线消息

4、 将离线消息推给用户。假设这10条离线消息最大msgid=110。

5、 App得到数据,判断得到的数据不为空(表明可能没有拉完离线数据,不用<10条做判断拉完条件,因为服务端需要下下次拉离线的请求来确定这次数据已送达),继续发起拉取操作。Msgid=110(取得到的离线消息中最大的msgid)。

6、 Im-server删除该用户msgid<110的离线消息(或者标记为已送达)。

7、 查询msgid>110的钱10条离线数据。

8、 返回给App

……

N-1、查询msgid>140的离线数据,0条(没有离线数据了)。

N 、将数据返回App,App判断拉取到0条数据,结束离线拉取过程。

1.2.3 PUSH

ISO采用APNS;Android真后台保活,同时增加米推、个推。

基本思路:push提示信息,App通过拉离线获得真实消息。

另附文档说明此问题。

2 协议设计

2.1 TCP数据协议

TCP的数据协议如下图所示。包括header和body两部分。

消息头总共20个字节,具体信息如下表。

2.2 TCP消息体设计

消息体协议采用ProtocolBuffer(谷歌)协议,版本3.0.0,该协议在序列化效率、压缩、可扩展方面都具有优势。协议条目见附录11.1.1TCP协议命令清单。以下为主要流程涉及的协议

2.2.1 认证(auth)

2.2.2 登出(logout)

2.2.3 踢人(kickout)

2.2.4 心跳(keepalive,noop)

心跳包消息体为空。

2.2.5 单对单聊天(c2c)

2.2.6 群聊(c2g)

2.2.7 拉离线(pull)

2.2.8 控制类(ctrl)

3 存储设计

3.1 MySQL数据库

MySQL数据库采用utf8mb4编码格式(emoji字符问题)

3.1.1 主要表结构

3.1.1.1 发送消息表

保存某个用户发送了哪些消息,用于复现用户聊天场景(消息漫游功能需要)。

3.1.1.2 推送消息表

保存某个用户收到了哪些消息

3.1.1.3 群相关表

群基本信息表

群用户关系表

3.1.2 水平分库

3.2 Redis缓存

3.2.1 用户状态及路由信息

Redis缓存以uid为key,检索channel(socketid),last_packet_time等。

Gate层,session以channel(socketed)为key,检索uid,及其他信息。

交互接口:gate->logic,通过将channel转换为uid作为key。

logic->gate,将uid转换为channel作为key。

3.2.2 其他缓存信息

你觉得该怎么存就怎么存。

3.3 文件及图片存储

采用商用云存储。

3.4 数据归档

可考虑采用HBase,HDFS作为数据归档,或者相关云存储服务。

本文分享自微信公众号 - V社 北京社(SoftwareTesters)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-07-28

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 一个海量在线用户即时通讯系统(IM)的完整设计Plus

    《一个海量在线用户即时通讯系统(IM)的完整设计》(以下称《完整设计》)这篇文章发出来之后有不少读者咨询问题,提出意见或建议。主要集中在模块拆分、协议、存储等方...

    普通程序员
  • 一个海量在线用户即时通讯系统(IM)的完整设计

    移动端重点是移动端,支持IOS/Android系统,包括IM App,嵌入消息功能的瓜子App,未来还可能接入客服系统。

    普通程序员
  • IM开发基础知识补课:正确理解前置HTTP SSO单点登陆接口的原理

    一个安全的信息系统,合法身份检查是必须环节。尤其IM这种以“人”为中心的社交体系,身份认证更是必不可少。

    JackJiang
  • 京东京麦商家开放平台的消息推送架构演进之路

    京麦实时消息推送是京东的京麦商家开放平台的核心组成部分。从消息源到消息中心再到触达用户,以及最终根据消息协议呼起操作页面,京麦实时消息推送是一个完整且健康的生态...

    JackJiang
  • IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议

    IM应用从服务端数据的角度来看,它是一种很特殊的应用场景,抛开基础数据、增值业务和附属功能不谈,单从IM聊天工具的立身之本——聊天数据来说,理论上是不需要在服务...

    JackJiang
  • 子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践

    自从2018年8月20日子弹短信在锤子发布会露面之后(详见《老罗最新发布了“子弹短信”这款IM,主打熟人社交能否对标微信?》),关于它的讨论不绝于耳,7 天融资...

    JackJiang
  • 新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践

    随着社会的发展、互联网技术的进步,以前的大型机服务端架构很显然由于高成本、难维护等原因渐渐地变得不再那么主流了,替代它的就是当下最火的互联网分布式架构。

    JackJiang
  • IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?

    一个完善的IM系统中通常充斥着大量的图片内容,包括:用户头像、图片消息、相册、图片表情等等,那么在做服务端架构设计时该如何存储这些图片呢?

    JackJiang
  • 基于消息总线的高可扩展性IM系统后台架构设计

    如果你还不了解IM系统的整体结构,可以先看看《一个海量在线用户即时通讯系统(IM)的完整设计》(一下简称《IM完整设计》)这篇文章。

    普通程序员
  • IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列

    消息是互联网信息的一种表现形式,是人利用计算机进行信息传递的有效载体,比如即时通讯网坛友最熟悉的即时通讯消息就是其具体的表现形式之一。

    JackJiang
  • 微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)

    对于IM系统来说,如何做到IM聊天消息离线差异拉取(差异拉取是为了节省流量)、消息多端同步、消息顺序保证等,是典型的IM技术难点。

    JackJiang
  • 从 1v1 到百万师生互动,教育机构如何提升在线教育技术能力

    疫情期间,巨额投资、百亿营销、监管趋严……2020年以来,曲折发展的教育行业已然进入全新赛段,那就是在线教育。

    云巴巴严选云
  • Netty干货分享:京东京麦的生产级TCP网关技术实践总结

    京东的京麦商家后台2014年构建网关,从HTTP网关发展到TCP网关。在2016年重构完成基于Netty4.x+Protobuf3.x实现对接PC和App上下行...

    JackJiang
  • ​稳健、可靠全真即时通信网的架构与应用

    导 语 支撑全真互联网的基础网络包括实时音视频通信网络、即时通信网络和流媒体分发网络。随着社会的进步,人们对低延时即时通信的需求越来越高。本次LiveVide...

    腾讯云音视频
  • 大规模群消息推送如何保证实时性?

    第一版红包功能上线后,收集到不少问题。核心问题是消息延迟,导致有些人先看到红包,有些人晚看到红包,同时导致消息顺序混乱。

    普通程序员
  • 私有化IM来啦!

    ? 背景: 在移动互联网时代,即时通信是一种最基础的产品场景。但当前主流的即时通信软件,对一些企业,特别是对于政务、金融、医疗等领域的企业来说,数据不够安全,...

    腾讯云音视频
  • 微信朋友圈千亿访问量背后的技术挑战和实践总结

    微信朋友圈包括图片和视频两套业务架构组成,朋友圈图片的特点是请求量大、消耗计算资源较多,视频则主要消耗带宽。

    JackJiang
  • 全面解密QQ红包技术方案:架构、技术实现、移动端优化、创新玩法等

    自 2015 年春节以来,QQ 春节红包经历了企业红包(2015 年)、刷一刷红包(2016 年)和 AR 红包(2017 年)几个阶段,通过不断创新玩法,活跃...

    JackJiang
  • 适合新手:从零开发一个IM服务端(基于Netty,有完整源码)

    站长提示:本文适合IM新手阅读,但最好有一定的网络编程经验,必竟实践性的代码上手就是网络编程。如果你对网络编程,以及IM的一些理论知识知之甚少,请务必首先阅读:...

    JackJiang

扫码关注云+社区

领取腾讯云代金券