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

JackJiang · 7 年前

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

1、写在前面

1.1、引言

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

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

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

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

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

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

本文作者：

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

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

1.2、参考资料

[1] IM架构方面的文章：
《浅谈IM系统的架构设计》
《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》
《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
《一套原创分布式即时通讯(IM)系统理论架构方案》
《从零到卓越：京东客服即时通讯系统的技术架构演进历程》
《蘑菇街即时通讯/IM服务器开发之架构选择》
《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》
《微信后台基于时间序的海量数据冷热分级架构设计实践》
《微信技术总监谈架构：微信之道——大道至简(演讲全文)》
《如何解读《微信技术总监谈架构：微信之道——大道至简》》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《17年的实践：腾讯海量产品的技术方法论》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《现代IM系统中聊天消息的同步和存储方案探讨》
《IM开发基础知识补课(二)：如何设计大量图片文件的服务端存储架构？》
《IM开发基础知识补课(三)：快速理解服务端数据库读写分离原理及实践建议》
《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《WhatsApp技术实践分享：32人工程团队创造的技术神话》
《微信朋友圈千亿访问量背后的技术挑战和实践总结》
《王者荣耀》2亿用户量的背后：产品定位、技术架构、网络方案等》
>> 更多同类文章 ……

[2] IM热点问题总结文章：
《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《IM开发基础知识补课：正确理解前置HTTP SSO单点登陆接口的原理》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
《如何保证IM实时消息的“时序性”与“一致性”？》
《一个低成本确保IM消息时序的方法探讨》
《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
《IM群聊消息如此复杂，如何保证不丢不重？》
《谈谈移动端 IM 开发中登录请求的优化》
《移动端IM登录时拉取数据如何作到省流量？》
《浅谈移动端IM的多点登陆和消息漫游原理》
《完全自已开发的IM该如何设计“失败重试”机制？》
《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
《QQ音乐团队分享：Android中的图片压缩技术详解（上篇）》
《QQ音乐团队分享：Android中的图片压缩技术详解（下篇）》
《腾讯原创分享(一)：如何大幅提升移动网络下手机QQ的图片传输速度和成功率》
《腾讯原创分享(二)：如何大幅压缩移动网络下APP的流量消耗（上篇）》
《腾讯原创分享(三)：如何大幅压缩移动网络下APP的流量消耗（下篇）》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《基于社交网络的Yelp是如何实现海量用户图片的无损压缩的？》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《为什么说即时通讯社交APP创业就是一个坑？》
>> 更多同类文章 ……

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 · 11 天前

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

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

66 楼: 穷屌丝2 · 11 天前

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

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

65 楼: 穷屌丝2 · 11 天前

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

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

64 楼: JackJiang · 13 天前

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

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

63 楼: 穷屌丝2 · 14 天前

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

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 · 3 年前

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

嗯呢，可行

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

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

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

54 楼: JackJiang · 3 年前

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

保存到数据库

53 楼: 张文-im · 3 年前

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

52 楼: 吾心_XePPa · 3 年前

感谢分享，谢谢大神

51 楼: wangfen_cread · 4 年前

学习了，收益良多！

50 楼: zhoufulin · 5 年前

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

49 楼: lee0607 · 5 年前

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

本文目录

1、写在前面

1.1、引言

1.2、参考资料

2、服务器端设计

2.1、总体架构设计