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

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

1、写在前面

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

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

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

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

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

• 《适合新手：从零开发一个IM服务端（基于Netty，有完整源码）》
• 《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》
• 《自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》
• 《一种Android端IM智能心跳算法的设计与实现探讨（含样例代码）》
• 《手把手教你用Netty实现网络通信程序的心跳机制、断线重连机制》
• 《一个WebSocket实时聊天室Demo：基于node.js+socket.io [附件下载]》
  

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

• 《一套海量在线用户的移动端IM架构设计实践分享(含详细图文)》
• 《即时通讯安全篇（七）：用JWT技术解决IM系统Socket长连接的身份认证痛点》
• 《移动端IM中大规模群消息的推送如何保证效率、实时性？》
• 《一个低成本确保IM消息时序的方法探讨》
• 《从零开始搭建瓜子二手车IM系统(PPT) [附件下载]》
• 《瓜子IM智能客服系统的数据架构设计(PPT) [附件下载]》
• 《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》
  

本文作者：

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

2、服务器端设计

2.1、总体架构设计

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


各层级的说明如下：

• 用户端：
  移动端重点是移动端，支持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系统核心组件及其协作关系，结构图如下：


客户端从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)流程原理

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

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

群聊流程如下图所示：


群聊流程详细说明：

• 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，拉取离线消息流程如下：

• 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两部分：


消息头总共20个字节，具体信息如下表：

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

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

认证(auth) ：


登出(logout) ：


踢人(kickout) ：


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

单对单聊天（c2c）：



群聊（c2g）：



拉离线（pull）：


控制类（ctrl）协议：

4、存储设计

4.1、MySQL数据库

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

4.2、主要表结构

发送消息表：
保存某个用户发送了哪些消息，用于复现用户聊天场景（消息漫游功能需要）。


推送消息表：
保存某个用户收到了哪些消息。


群基本信息表：


群用户关系表：

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开发资料汇总

[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亿用户量的背后：产品定位、技术架构、网络方案等》
《IM系统的MQ消息中间件选型：Kafka还是RabbitMQ？》
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《以微博类应用场景为例，总结海量社交系统的架构设计步骤》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（容灾方案篇）》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》
《社交软件红包技术解密(二)：解密微信摇一摇红包从0到1的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
《社交软件红包技术解密(八)：全面解密微博红包技术方案》
《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》
《社交软件红包技术解密(十二)：解密抖音春节红包背后的技术设计与实践》
《社交软件红包技术解密(十三)：微信团队首次揭秘微信红包算法，为何你抢到的是0.01元》
《即时通讯新手入门：一文读懂什么是Nginx？它能否实现IM的负载均衡？》
《即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》
《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》
《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》
《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》
《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》
《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》
《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
《微信后台基于时间序的新一代海量数据存储架构的设计实践》
《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》
《IM开发基础知识补课(十)：大型IM系统有多难？万字长文，搞懂异地多活！》
《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》
《一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等》
《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》
《从新手到专家：如何设计一套亿级消息量的分布式IM系统》
《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》
《融云技术分享：全面揭秘亿级IM消息的可靠投递机制》
《IM开发技术学习：揭秘微信朋友圈这种信息推流背后的系统设计》
《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》
《阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠投递优化实践》
《阿里IM技术分享(五)：闲鱼亿级IM消息系统的及时性优化实践》
《阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化》
《阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践》
《阿里IM技术分享(八)：深度解密钉钉即时消息服务DTIM的技术设计》
《阿里IM技术分享(九)：深度揭密RocketMQ在钉钉IM系统中的应用实践》
《基于实践：一套百万消息量小规模IM系统技术要点总结》
《跟着源码学IM(十)：基于Netty，搭建高性能IM集群（含技术思路+源码）》
《一套十万级TPS的IM综合消息系统的架构实践与思考》
《直播系统聊天技术(八)：vivo直播系统中IM消息模块的架构实践》
《得物从0到1自研客服IM系统的技术实践之路》
《海量用户IM聊天室的架构设计与实践》
《企业微信针对百万级组织架构的客户端性能优化实践》
《小红书万亿级社交网络关系下的图存储系统的架构设计与实践》
《一套分布式IM即时通讯系统的技术选型和架构设计》
《陌陌技术分享：陌陌IM在后端KV缓存架构上的技术实践》
《微信团队分享：微信后端海量数据查询从1000ms降到100ms的技术实践》
《微信团队分享：来看看微信十年前的IM消息收发架构，你做到了吗》
《携程技术分享：亿级流量的办公IM及开放平台技术实践》
《百度公共IM系统的Andriod端IM SDK组件架构设计与技术实现》

[2] IM开发热点问题资料：
《新手入门一篇就够：从零开发移动端IM》
《移动端IM开发者必读(一)：通俗易懂，理解移动网络的“弱”和“慢”》
《移动端IM开发者必读(二)：史上最全移动弱网络优化方法总结》
《移动端IM开发者必读(三)：爱奇艺移动端跨国弱网通信的优化实践》
《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》
《现代移动端网络短连接的优化手段总结：请求速度、弱网适应、安全保障》
《腾讯技术分享：社交网络图片的带宽压缩技术演进之路》
《小白必读：闲话HTTP短连接中的Session和Token》
《IM开发基础知识补课：正确理解前置HTTP SSO单点登录接口的原理》
《移动端IM中大规模群消息的推送如何保证效率、实时性？》
《移动端IM开发需要面对的技术问题》
《开发IM是自己设计协议用字节流好还是字符流好？》
《请问有人知道语音留言聊天的主流实现方式吗？》
《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》
《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》
《如何保证IM实时消息的“时序性”与“一致性”？》
《一个低成本确保IM消息时序的方法探讨》
《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》
《IM群聊消息如此复杂，如何保证不丢不重？》
《谈谈移动端 IM 开发中登录请求的优化》
《移动端IM登录时拉取数据如何作到省流量？》
《浅谈移动端IM的多点登录和消息漫游原理》
《完全自已开发的IM该如何设计“失败重试”机制？》
《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
《微信对网络影响的技术试验及分析（论文全文）》
《即时通讯系统的原理、技术和应用（技术论文）》
《开源IM工程“蘑菇街TeamTalk”的现状：一场有始无终的开源秀》
《如约而至：微信自用的移动端IM网络层跨平台组件库Mars已正式开源》
《基于社交网络的Yelp是如何实现海量用户图片的无损压缩的？》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)》
《腾讯技术分享：腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)》
《全面掌握移动端主流图片格式的特点、性能、调优等》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《IM开发基础知识补课(五)：通俗易懂，正确理解并用好MQ消息队列》
《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》
《融云技术分享：解密融云IM产品的聊天消息ID生成策略》
《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《适合新手：从零开发一个IM服务端（基于Netty，有完整源码）》
《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》
《适合新手：手把手教你用Go快速搭建高性能、可扩展的IM系统(有源码)》
《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》
《IM开发基础知识补课(七)：主流移动端账号登录方式的原理及设计思路》
《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》
《IM要做手机扫码登录？先看看微信的扫码登录功能技术原理》
《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》
《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》
《IM开发干货分享：我是如何解决大量离线消息导致客户端卡顿的》
《零基础IM开发入门(二)：什么是IM系统的实时性？》
《零基础IM开发入门(三)：什么是IM系统的可靠性？》
《零基础IM开发入门(四)：什么是IM系统的消息时序一致性？》
《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》
《IM开发干货分享：有赞移动端IM的组件化SDK架构设计实践》
《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》
《IM扫码登录技术专题(一)：微信的扫码登录功能技术原理调试分析》
《IM扫码登录技术专题(二)：市面主流的扫码登录技术原理调试分析》
《IM扫码登录技术专题(三)：通俗易懂，IM扫码登录功能详细原理一篇就够》
《IM扫码登录技术专题(四)：你真的了解二维码吗？刨根问底、一文掌握！》
《理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨》
《阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践》
《融云技术分享：全面揭秘亿级IM消息的可靠投递机制》
《IM开发干货分享：万字长文，详解IM“消息“列表卡顿优化实践》
《IM全文检索技术专题(三)：网易云信Web端IM的聊天消息全文检索技术实践》
《IM开发技术学习：揭秘微信朋友圈这种信息推流背后的系统设计》
《阿里IM技术分享(六)：闲鱼亿级IM消息系统的离线推送到达率优化》
《阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践》
《探探的IM长连接技术实践：技术选型、架构设计、性能优化》
《IM开发干货分享：浅谈IM系统中离线消息、历史消息的最佳实践》
《IM开发干货分享：IM客户端不同版本兼容运行的技术思路和实践总结》
《字符编码那点事：快速理解ASCII、Unicode、GBK和UTF-8》
《IM开发基础知识补课(八)：史上最通俗，彻底搞懂字符乱码问题的本质》
《史诗级计算机字符编码知识分享，万字长文，一文即懂！》
《百度统一socket长连接组件从0到1的技术实践》
《淘宝移动端统一网络库的架构演进和弱网优化技术实践》
《得物自研移动端弱网诊断工具的技术实践分享》
《揭秘企业微信是如何支持超大规模IM组织架构的——技术解读四维关系链》
《抖音技术分享：飞鸽IM桌面端基于Rust语言进行重构的技术选型和实践总结》
《大型IM工程重构实践：企业微信Android端的重构之路》
《IM跨平台技术学习(十三)：从理论到实践，详细对比Electron和Tauri的优劣》

[3] 开源移动端IM技术框架资料：
《开源移动端IM技术框架MobileIMSDK：快速入门》
《开源移动端IM技术框架MobileIMSDK：常见问题解答》
《开源移动端IM技术框架MobileIMSDK：压力测试报告》
>> 更多同类文章 ……

虽然设计并不完美，但干货很多，感谢原作者的无私分享

写的这么详细，太感谢了！

建立与接入层的连接（可能为短连接） >>短连接有啥优势？

引用：charming 发表于 2017-05-12 15:34
建立与接入层的连接（可能为短连接） >>短连接有啥优势？

一般来说短连接就是说的HTTP了，HTTP这种标准服务好处太多了，基于http的负载均衡成熟方案一大把，还可以做成现在流行的所谓微服务，既然这样那为何还要混进IM协议里，还让其IM变的更复杂。总之好处多多，慢慢体会

引用：JackJiang 发表于 2017-05-12 15:44
一般来说短连接就是说的HTTP了，HTTP这种标准服务好处太多了，基于http的负载均衡成熟方案一大把，还可以 ...

谢谢楼主解答

学习了

统一登录的地方  怎么避免单点故障？

引用：ztcjn 发表于 2017-05-13 18:02
统一登录的地方  怎么避免单点故障？

如果提炼成HTTP服务的话可以用Nginx这些东西

引用：JackJiang 发表于 2017-05-13 18:03
如果提炼成HTTP服务的话可以用Nginx这些东西

我的意思是  登录用户状态信息的存放

请问，app来拉取数据的时候，服务端是如何操作的？从mysql里面查的嘛？

引用：nick_sw 发表于 2017-05-17 17:01
请问，app来拉取数据的时候，服务端是如何操作的？从mysql里面查的嘛？

可以这样，具体的架构可以自已按照现实情况去定，没有固定的套路

赞一个

感谢分享

很不错谢谢分享

感谢方案，收益良多

此方案中接入层和逻辑层是通过什么解耦的？mq还是rpc？

引用：sunnyhui2010 发表于 2017-07-13 22:05
此方案中接入层和逻辑层是通过什么解耦的？mq还是rpc？

要实时性好肯定是RPC，但主要看你的应用场景是看重性能还是实时性

学习学习

学习了 大神