一套海量在线用户的移动端IM架构设计实践分享(含详细图文)

JackJiang · 8 年前

本文原题为“一个海量在线用户即时通讯系统（IM）的完整设计”，来自IM技术交流群群友：封宇，感谢原作者（原文链接在文末）。

1、写在前面

如果在没有太多经验可借鉴的情况下，要设计一套完整可用的移动端IM架构，难度是相当大的。原因在于，IM系统（尤其是移动端IM系统）是多种技术和领域知识的横向应用综合体：网络编程、通信安全、高并发编程、移动端开发等，如果要包含实时音视频聊天的话，则还要加上难度更大的音视频编解码技术（内行都知道，把音视频编解码及相关技术玩透的，博士学位都可以混出来了），凡此种种，加上移动网络的特殊性、复杂性，设计和开发难度不言而喻。

本文分享了一套完整的海量在线用户的移动端IM架构设计，来自于作者的真实项目实践总结，包含了详细的算法原理图、数据结构定义、表结构定义等等。

即时通讯网注：本文中的架构设计从实际应用的角度看，其实并不完美，多处设计对于高吞吐高并发的IM应用来说也是存在单点性能瓶颈的（比如：提供消息交换逻辑的msg_logic服务、提供全局用户状态查询的单点Redis等），另外IM协议设计可能也稍显混乱（但这是仁者见仁智者见者的事了，不能一概而论）。但文章中的大部分算法原理、协议设计等都是值得借鉴的，总之没必要照搬，但至少能给你自已的方案设计带来灵感，我想这也是本文或即时通讯网的其它类似文章的真正价值所在。

另外，如果您正打算从零开发移动端IM，则建议您从《新手入门一篇就够：从零开发移动端IM》一文开始，此文按照IM开发所需的知识和技能要求，拟定了详尽的学习提纲和建议等。

另外，以下几篇有关IM实际动手开发的文章也值得一读，有兴趣可以看看：

本文作者封宇分享的其它IM技术资料：

本文作者：

一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_152744v2drcr9sqdir2ql4.jpg

封宇，瓜子二手车技术专家，中国计算机学会专业会员。主要负责瓜子即时消息解决方案及相关系统研发工作。曾供职于58同城、华北计算技术研究所，参与到家消息系统、58爬虫系统以及多个国家级军工科研项目的架构及研发工作。

2、服务器端设计

2.1、总体架构设计

总体架构包括5个层级，具体内容如下图：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_1.jpg

各层级的说明如下：

用户端：
移动端重点是移动端，支持IOS/Android系统，包括IM App，嵌入消息功能的瓜子App，未来还可能接入客服系统；
用户端API：
针对TCP协议，提供IOS/Android开发SDK。对于H5页面，提供WebSocket接口；
接入层：
接入层主要任务是保持海量用户连接（接入）、攻击防护、将海量连接整流成少量TCP连接与逻辑层通讯；
逻辑层：
逻辑层负责IM系统各项功能的核心逻辑实现。包括单聊（c2c）、上报(c2s)、推送(s2c)、群聊(c2g)、离线消息、登录授权、组织机构树等等内容；
存储层：
存储层负责缓存或存储IM系统相关数据，主要包括用户状态及路由（缓存），消息数据（MySQL也可采用NoSql，如MangoDB），文件数据（文件服务器）。

2.2、典型算法逻辑

典型算法逻辑部分描述IM系统核心组件及其协作关系，结构图如下：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_2.jpg

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

以下将对各子业务的工作原理进行逐一介绍。

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状态，并向客户端返回授权结果。

2.2.2登出(logout)流程原理

1、客户端发起logout请求，msg-gate设置对应Peer为未登录状态。
2、Msg-gate给客户端一个ack响应。
3、Msg-gate通知msg-logic用户登出。

2.2.3踢人(kickout)流程原理

用户请求授权时，可能在另一个设备（同类型设备）开着软件处于登录状态，这种情况需要系统将那个设备踢下线，如下图：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_5.jpg

1-5步，参看Auth流程。
6、Logic检索Redis，查看是否该用户在其他地方登录。
7、如果在其他地方登录，发起kickout命令。（如果没有登录，整个流程结束）
8、Gate向用户发起kickout请求，并在短时间内（确保客户端收到kickout数据）关闭socket连接。

2.2.4上报(c2s)流程原理

1、客户端向gate发送数据；
2、Gate回一个ack包，向客户端确认已经收到数据；
3、Gate将数据包传递给logic；
4、Logic根据数据投递目的地，选择对应的mq队列进行投递；
5、业务服务器得到数据。

2.2.5推送(s2c)流程原理

1、业务线调用push数据接口sendMsg
2、Logic向redis检索目标用户状态。如果目标用户不在线，丢弃数据（未来可根据业务场景定制化逻辑）；如果用户在线，查询到用户连接的接入层gate
3、Logic向用户所在的gate发送数据
4、Gate向用户推送数据。（如果用户不在线，通知logic用户不在线）
5、客户端收到数据后向gate发送ack反馈
6、Gate将ack信息传递给logic层，用于其他可能的逻辑处理（如日志，确认送达等）

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、米推、个推进行推送。

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离线，期望未来拉取到离线消息。

群聊流程如下图所示：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_9.jpg

群聊流程详细说明：

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的时间。然后在通过一个定时任务，每隔一定时间，将数据更新到数据库（注意只需要写入时间段内有变化的数据）。

2.2.8拉取离线消息流程原理

下图中，将gate和logic合并为im-server，拉取离线消息流程如下：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_10.jpg

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条数据，结束离线拉取过程。

2.3、后台PUSH（推送）

iOS采用APNS，Android真后台保活，同时增加米推、个推。基本思路：push提示信息，App通过拉离线获得真实消息。

3、协议设计

3.1、IM协议总体定义

TCP的数据协议如下图所示，包括header和body两部分：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_11.jpg

消息头总共20个字节，具体信息如下表：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_12.jpg

3.2、各具体的IM协议体定义

消息体协议采用ProtocolBuffer（谷歌）协议（详见文章《Protobuf通信协议详解：代码演示、详细原理介绍等》），版本3.0.0，该协议在序列化效率、压缩、可扩展方面都具有优势。以下为主要流程涉及的协议。

认证(auth) ：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_13.jpg

登出(logout) ：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_14.jpg

踢人(kickout) ：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_15.jpg

心跳（keepalive,noop）：
心跳包消息体为空。

单对单聊天（c2c）：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_16.jpg

群聊（c2g）：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_18.jpg

拉离线（pull）：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_20.jpg

控制类（ctrl）协议：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_21.jpg

4、存储设计

4.1、MySQL数据库

MySQL数据库采用utf8mb4编码格式（emoji字符问题）。

4.2、主要表结构

发送消息表：
保存某个用户发送了哪些消息，用于复现用户聊天场景（消息漫游功能需要）。
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_22.jpg

推送消息表：
保存某个用户收到了哪些消息。
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_23.jpg

群基本信息表：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_24.jpg

群用户关系表：
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)_25.jpg

4.3、水平分库

4.4、Redis缓存

用户状态及路由信息：
Redis缓存以uid为key，检索channel(socketid)，last_packet_time等。
Gate层，session以channel(socketed)为key，检索uid，及其他信息。
交互接口：gate->logic，通过将channel转换为uid作为key。
logic->gate，将uid转换为channel作为key。

其他缓存信息：
你觉得该怎么存就怎么存。

4.5、文件及图片存储

采用商用云存储。

4.6、数据归档

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

安全部分略，其他非核心功能略。

（原文链接：点此进入，有改动）

附录：更多IM开发资料汇总

67 楼: JackJiang · 6 个月前

引用：穷屌丝2 发表于 2024-11-11 14:55
是的确实没有分页，但是如果没有会话表，它就要去消息表去做会话列表的筛选提取，这个效率可就很低了。

肯定要存表了，你可以研究一下这个《微信本地数据库破解版(含iOS、Android)，仅供学习研究 [附件下载]》

66 楼: 穷屌丝2 · 6 个月前

引用：JackJiang 发表于 2024-11-09 11:22
这个首页会话页，一般没必要分页加载，会话也分而加载太影响体验了，微信是全部加载，qq以前的版本是老的 ...

是的确实没有分页，但是如果没有会话表，它就要去消息表去做会话列表的筛选提取，这个效率可就很低了。

65 楼: 穷屌丝2 · 6 个月前

引用：JackJiang 发表于 2024-11-09 11:22
这个首页会话页，一般没必要分页加载，会话也分而加载太影响体验了，微信是全部加载，qq以前的版本是老的 ...

微信显示确实是，但它后端有没有表就不知道了。不做的话，后续的对会话未读的统计，那就应该比较麻烦和效率低了。

64 楼: JackJiang · 6 个月前

引用：穷屌丝2 发表于 2024-11-08 10:11
会话表不需要设计吗，用户进来后会话一般都要分页加载的，这个表是否也是必要设计的一项。

这个首页会话页，一般没必要分页加载，会话也分而加载太影响体验了，微信是全部加载，qq以前的版本是老的会话直接忽略，新的版本也是全部显示。

63 楼: 穷屌丝2 · 6 个月前

会话表不需要设计吗，用户进来后会话一般都要分页加载的，这个表是否也是必要设计的一项。

62 楼: JackJiang · 2 年前

引用：BrainWong 发表于 2022-08-30 23:28
看到站长的这篇文章，了解很多常识: )

嗯

61 楼: BrainWong · 2 年前

引用：JackJiang 发表于 2022-08-30 10:58
这，该怎么回答。。
等你工作经验多了，应该就能体会到为什么要用mq了

引用：http://www.52im.net/thread-1979-1-1.html

看到站长的这篇文章，了解很多常识: )

60 楼: JackJiang · 2 年前

引用：BrainWong 发表于 2022-08-29 22:28
为什么登出的时候不需要在SSO上注销?

能主动注销自然最好，但很多时候是非常退出啊

59 楼: JackJiang · 2 年前

引用：BrainWong 发表于 2022-08-29 22:47
看了好多架构都使用了消息队列，但是想不出来，消息队列怎么解耦?

这，该怎么回答。。
等你工作经验多了，应该就能体会到为什么要用mq了

58 楼: BrainWong · 2 年前

看了好多架构都使用了消息队列，但是想不出来，消息队列怎么解耦?

57 楼: BrainWong · 2 年前

为什么登出的时候不需要在SSO上注销?

56 楼: JackJiang · 4 年前

引用：ゞ雪☆痕の发表于 2021-03-16 15:41
我们的做法是把最近7日的数据存到redis，然后其他数据存到MySQL中

嗯呢，可行

神秘人 *发表于 4 年前* · 发表于 4 年前

引用：张文-im 发表于 2021-01-16 22:46
请问离线数据是保存在redis中吗？保存多久？假如redis满了是不是会丢数据？

我们的做法是把最近7日的数据存到redis，然后其他数据存到MySQL中

54 楼: JackJiang · 4 年前

引用：张文-im 发表于 2021-01-16 22:46
请问离线数据是保存在redis中吗？保存多久？假如redis满了是不是会丢数据？

保存到数据库

53 楼: 张文-im · 4 年前

请问离线数据是保存在redis中吗？保存多久？假如redis满了是不是会丢数据？

52 楼: 吾心_XePPa · 4 年前

感谢分享，谢谢大神

51 楼: wangfen_cread · 5 年前

学习了，收益良多！

50 楼: zhoufulin · 5 年前

不太明白TCP包头命令号和TCP包头seq这两个字段什么，求大神指教

49 楼: lee0607 · 5 年前

文中好像没有提及到会话的创建以及更新哎还有未读数量什么的

本文目录

1、写在前面

2、服务器端设计

2.1、总体架构设计