本文由阿里闲鱼技术团队今朝、有攸分享，本次有修订。

1、引言

闲鱼即时消息系统历经数代迭代，目前已能稳定的支撑亿级消息体量。

在此消息系统的建设过程中，我们经历了从简单到复杂、从困扰到破局，每一次的技术改变都是为了更好的解决当下业务所面临的问题。

本文分享的是闲鱼即时消息系统架构从零开始的技术变迁之路，以期更多的同行们在此基础上汲取经验，得到有价值的启发。

学习交流：

- 即时通讯/推送技术开发交流5群：215477170 [推荐]

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK

（本文同步发布于：http://www.52im.net/thread-3699-1-1.html ）

2、系列文章

本文是系列文章的第3篇，总目录如下：

1. 《阿里IM技术分享(一)：企业级IM王者——钉钉在后端架构上的过人之处》
2. 《阿里IM技术分享(二)：闲鱼IM基于Flutter的移动端跨端改造实践》
3. 《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》（* 本文）
4. 《阿里IM技术分享(四)：闲鱼亿级IM消息系统的可靠性投递技术实践》（* 稍后发布）

3、1.0版：业务初创期、最小化可用

3.1 技术背景

2014年启动闲置交易独立APP “闲鱼”，一期构建完成APP主链路，包含商品：发布→搜索→商品详情→IM会话→交易。

作为初创app，业务需尽快上线验证效果，技术建设上需要完成闲鱼消息从无到有的系统搭建。

3.2 技术方案

作为即时通讯系统，最小化能力包含：

• 1）消息存储：会话、摘要、消息；
• 2）消息同步：推、拉；
• 3）消息通道：长连接、厂商推送。

与一般IM会话模型不同的是，闲鱼会话以商品为主体，“人＋人+商品”为要素构建会话。

因会话模型的差异，淘系已有的消息系统，短期内无法满足业务需求，而闲鱼完全自建消息系统耗时巨大。

为了保障业务高效上线，技术选型上最大化复用已有系统能力，避免重复造轮子。

所以，我们的技术方案是：

• 1）数据模型与底层存储依赖淘系私信体系进行建设；
• 2）消息数据获取上，客户端全量从服务端拉取消息数据；
• 3）通讯协议使用来往SDK及mtop。

总体架构如下图，以此模式完成快速交付保障了业务最小化可用：

4、2.0版：用户量增速快、需要重建消息系统

4.1 技术背景

闲鱼用户量正快速突破100万，即时消息服务的调用量暴涨。在这样的背景下，用户反馈消息数据获取的卡顿、白屏成为常态，大量的消息Push发送下，系统告警频发。

造成这些问题的原因：1.0版的架构模式下，获取消息数据全量拉模式，客户端纯UI不做数据存储。

具体就是：

• 1）当用户需要查看消息数据时，数据拉取成功与否取决于网络、数据访问速度，偶发性的造成卡顿、白屏；
• 2）中心化的数据存储，读远大于写，高并发下，服务端负载过大。

针对第2）点：比如1W个用户同时在线聊天，按照当前架构并发拉取全量消息，估算5万QPS。不妨假设，同时在线聊天用户数10万时，对服务端压力可想而知。

4.2 技术方案

基于上述问题，我们决定重建消息系统架构，以应对未来更大的用户增量。

回归到IM系统的核心功能：

4.2.1）消息存储模型：

• 1）会话模型：由owner、itemid、user、sessionType 来标识唯一会话，增加扩展属性支持个性化；
• 2）摘要模型：作为用户会话视图，同一会话的不同用户可个性化呈现，由userid、sid标识唯一摘要；
• 3）消息模型：由sender、消息内容、消息版本、sid组成。sid+消息版本唯一确定一条消息；
• 4）指令模型：是一种双端约定，由服务端下发，客户端执行的指令集。如免打扰指令、删除指令等。

4.2.2）消息通道：

1）在线通道：使用淘宝无线ACCS长连接提供的全双工、低延时、高安全的通道服务；

2）离线通道：使用淘宝消息推送平台AGOO. 其屏蔽了各主流厂商对接的复杂度，直接对业务系统提供服务。

4.2.3）消息同步模型：

1）客户端建立数据库，存储消息数据：当消息数据存储在本地设备上，消息同步从全量拉取优化为全量+增量同步结合的模式。

增量和全量同步具体指的是：

• a. 增量同步：客户端存储消息位点信息，通过与服务端最新位点比较，仅同步增量消息；
• b. 全量同步：当用户卸载重装或位点gap过大时，客户端全量拉取历史消息数据，进行端上数据重建。

2）服务端建设个人消息域环(收件箱模型)：以和客户端进行增量数据同步。同时，1.0版本架构中存在的读多写少的问题，通过个人域环的写扩散来平衡读写压力。

下图为一条消息从发送到接收的过程以及服务端和客户端的执行流程：

如上图所示：假设Ua给Ub发送一条消息，消息写扩散至Ua和Ub的各自的域环中：

• 1）当客户端online时，接收到推送的消息位点=当前端上域版本+1，本地消息数据库merge即可；
• 2）当客户端offline时，仅进行离线推送通知，当用户重新上线时，进行数据同步，由服务端判断触发增量同步还是全量同步。

针对第2）点，具体逻辑是：

• 1）如果域环版本差值小于阀值，增量同步后，进行本地消息数据库merge；
• 2）当域环版本差值大于阀值，进行全量消息拉取，做端上数据重建。

整个同步逻辑基于闲鱼的即时消息域环，域环可以看作是有着固定容量的用户消息收件箱，给一个用户发送的所有消息都会同步到他的域环中。

具体就是：

• 1）域环存储：域环需要支持高并发数据读写，使用阿里分布式KV存储系统tair来实现；
• 2）域环容量：为减少全量消息同步，以用户下次进入闲鱼需要同步的平均消息量来规划个人域环容量。同时利用FIFO循环覆盖历史数据；
• 3）域环版本：用户当前消息位点，在消息进入个人域环时通过tair的counter实现域环版本严格连续递增，用于全量、增量同步判断。

上述建设完成后，闲鱼具备了自己独立的即时消息系统，当下遇到的问题得到了缓解，用户体验度有大幅提升。

5、3.0版：随着业务快速发展，系统稳定性需得到保障

5.1 技术背景

随着闲鱼业务生态的丰富，IM会话与消息内容类型不断扩展，同时在用户量的快速增长下，用户反馈消息收不到、消息延迟等舆情问题日渐突出。

5.2 问题分析

问题1：闲鱼app进程无有效保活机制，app退到后台后进程很快就会被系统挂起，导致长连接中断。此时消息推送走厂商通道，而厂商通道的实时性较差，且对消息推送的优先级设定有差异，从而造成用户感知消息延迟。

问题2：accs在线消息推送时，平均延时较短，但存在假连情况。而且目前的消息推送链路无ack机制，造成服务端以为消息发出去了但实际上客户端并没有收到，用户下次打开app后才能看到消息，用户感知消息延迟。

PS：造成假连接的原因主要是用户退到后台，accs长连中断，但是设备状态更新有延时。

问题3：目前消息同步的推模式(accs push)、拉模式(mtop)，客户端未做隔离，异步进行处理，导致在某些极端情况下消息数据库处理异常，引发消息丢失。

如：某用户上线后连续收到多条消息，其中一条触发域黑洞，在进行消息同步端上数据重建时，小概率处理出错。

问题4：大部分线上消息问题发现靠舆情反馈，如消息错乱，出问题后系统无感知、无补救措施且排查困难，仅能跟随版本做修复。

问题5：业务不断丰富，孵化出基于消息系统的服务号及小程序内容营销、消息群组等，各类消息发送链路共用域环与数据存储，造成稳定性问题。

如：个人域环的消息包括IM聊天和营销消息，IM聊天由用户触发，需要保证强到达；而营销消息一般是由系统通过班车等方式批量发送，消息量级大，tps高，影响IM服务稳定性。

5.3 解案决方案

基于上述分析，我们逐个问题进行专项解决。

1）消息重发与推拉隔离：

如上图所示：

• a. ACK：保障消息及时到达。服务端下行accs消息时，将消息加入重试队列并延迟重试，客户端在收到accs消息并处理成功后，给服务端回一个ack，服务端收到ack后更新消息到达状态，并终止重试，以此避免设备假连或网络不稳定的情况；
• b. 重发：根据延迟重发策略决定何时重发消息，保障消息确定性到达。自适应延迟重发策略是指新消息先通过4次固定N秒的短延迟来探测设备的网络状况，然后根据网络状况来递增固定步长M的延迟策略，这种策略可以保障在最短的时间内，使用最少的重发次数将消息投递成功；
• c. 消息队列：端上引入消息队列，按顺序处理消息，保证消息处理的准确性。同时进行推拉隔离，保障队列有序消费，解决了复杂状况下并发处理消息数据合并出错的问题。

2）数据存储拆分：

闲鱼每天发送的即时消息中有一半以上是营销消息，营销消息的发送具有明显的波峰波谷流量，高峰期会导致消息数据库抖动，影响IM消息。我来对消息、摘要、域环存储做业务隔离，以适应不同业务场景对稳定性不同的要求。

具体做法是：

• 1）IM消息需要极高的稳定性保证，其消息及摘要继续使用mysql存储；
• 2）营销消息存储周期短，稳定性要求低于IM，采用Lindorm存储；
• 3）域环做实例级别隔离，保证IM域环的容量不会被其他消息占用，从而影响到消息同步。

PS：Lindorm是一种多模型的云原生数据库服务，具有成本低、自定义TTL、容量横向扩展等优势。

3）线上问题发现与恢复：

保障稳定性的关键要素是做好各种核心指标的监控，而监控首先要有数据来源，对服务端+客户端的关键链路节点埋点，基于集团UT、SLS，通过blink进行实时清洗、计算，最终形成统一规范的日志数据落至SLS，以供实时监控及链路排查。

消息系统的核心目标是保障用户消息发的出、收得到且及时收到，所以我们通过计算发送成功率、到达率、消息延迟来监控系统的稳定性。

此外，为了解决用户舆情排查困难的问题：

• 1）我们设计了一套指令集，通过约定指令协议，服务端向指定用户下发指令，客户端执行对应指令进行异常数据上报，提高排查效率；
• 2）扩展了强制全量同步、数据校正等指令，定向修复用户消息数据问题，相较以往出现严重bug只能让用户卸载重装解决，这种方式显然对用户是更友好的。

经过一系列专项治理，技术类舆情下降50%，从0到1建设了消息稳定性体系，用户体验进一步提升。

6、展望未来

闲鱼作为电商交易APP， 其中IM是交易的前置链路，IM的产品体验极大影响用户交易效率。

前段时间进行用户调研，从闲鱼IM的NPS低于预期（NPS是用户忠诚度衡量指标 = 推荐者%-贬损者%）。

从用户反馈来看：

• 1）部分用户对产品功能有较强烈的诉求，诸如消息搜索、分组等；
• 2）大部分用户对发送消息过程中的违规问题难以理解；
• 3）仍有较多舆情反馈消息收不到或延迟。

映射到目前闲鱼的即时消息系统上，我们的系统架构依然有很多需要持续改进的地方。

典型的如：同步协议冗余，在需求迭代过程中容易引发问题、有效保活机制的缺失对消息即时送达的影响、小众机型离线消息收不到、多年的数据积累在线库臃肿等问题，影响着闲鱼业务迭代速度与NPS。

作为技术团队，下一步将提升NPS作为核心技术目标，闲鱼的即时消息系统4.0版架构正在路上 ......

附录：更多相关文章

[1] 更多阿里巴巴的技术资源：

《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》

《现代IM系统中聊天消息的同步和存储方案探讨》

《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》

《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》

《来自阿里OpenIM：打造安全可靠即时通讯服务的技术实践分享》

《钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT) [附件下载]》

《阿里技术结晶：《阿里巴巴Java开发手册(规约)-华山版》[附件下载]》

《重磅发布：《阿里巴巴Android开发手册(规约)》[附件下载]》

《作者谈《阿里巴巴Java开发手册(规约)》背后的故事》

《《阿里巴巴Android开发手册(规约)》背后的故事》

《干了这碗鸡汤：从理发店小弟到阿里P10技术大牛》

《揭秘阿里、腾讯、华为、百度的职级和薪酬体系》

《淘宝技术分享：手淘亿级移动端接入层网关的技术演进之路》

《难得干货，揭秘支付宝的2维码扫码技术优化实践之路》

《淘宝直播技术干货：高清、低延时的实时视频直播技术解密》

《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》

《阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践》

《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》

 

[2] 有关IM架构设计的文章：

《浅谈IM系统的架构设计》

《简述移动端IM开发的那些坑：架构设计、通信协议和客户端》

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

《一套原创分布式即时通讯(IM)系统理论架构方案》

《从零到卓越：京东客服即时通讯系统的技术架构演进历程》

《蘑菇街即时通讯/IM服务器开发之架构选择》

《腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT》

《微信后台基于时间序的海量数据冷热分级架构设计实践》

《微信技术总监谈架构：微信之道——大道至简(演讲全文)》

《如何解读《微信技术总监谈架构：微信之道——大道至简》》

《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》

《移动端IM中大规模群消息的推送如何保证效率、实时性？》

《现代IM系统中聊天消息的同步和存储方案探讨》

《微信朋友圈千亿访问量背后的技术挑战和实践总结》

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

《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》

《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》

《社交软件红包技术解密(一)：全面解密QQ红包技术方案——架构、技术实现等》

《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》

《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》

《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》

《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》

《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》

《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》

《一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等》

《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》

《从新手到专家：如何设计一套亿级消息量的分布式IM系统》

《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》

《融云技术分享：全面揭秘亿级IM消息的可靠投递机制》

《IM开发技术学习：揭秘微信朋友圈这种信息推流背后的系统设计》

《阿里IM技术分享(三)：闲鱼亿级IM消息系统的架构演进之路》

>> 更多同类文章 ……

本文已同步发布于“即时通讯技术圈”公众号。

同步发布链接是：http://www.52im.net/thread-3699-1-1.html 

本文由融云技术团队原创分享，原题“技术实践丨万人群聊的消息分发控速方案”，为使文章更好理解，内容有修订。

1、引言

传统意义上的IM群聊，通常都是像微信这样的500人群，或者QQ的2000人群（QQ有3000人群，但那是单独收费的，也就意味着它并非无门槛标配，能用上的人并不多）。

自从国外某号称“世界上最安全的IM”搞出万人群聊之后，万人群迅速被国内的使用者们接受。伴随着移动互联网的发展，即时通讯服务被广泛应用于各个行业（以经不再局限于传统IM社交应用领域），随着业务快速发展，传统百人、千人上限的群聊已经无法满足很多业务场景需求，所以万人甚至十万人的超大群也算是相伴而生、顺应潮流。 

▲ “纸飞机”的万人群（开发人员颤抖中...）

IM群聊一直是IM应用中比较有难度的热点技术之一，通常意义的群聊，无非就是500人群、1000人群、2000人群这样，技术实现上比单聊要复杂不少。然而对于万人群聊（甚至十万人群聊）来说，相比百人、千人群聊，技术实现上那几乎是另一个技术维度的事情，难度要高很多。

本文根据融云技术团队的实践经验，总结了万人群聊消息投递方案的一些思考和实践，希望能给你带来启发。

学习交流：

（本文同步发布于：http://www.52im.net/thread-3687-1-1.html）

2、相关文章

万人群聊有关的技术文章还可读一读以下这篇：

1. 《网易云信技术分享：IM中的万人群聊技术方案实践总结》
2. 《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》
3. 《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》

融云技术团队分享的其它文章：

1. 《融云技术分享：融云安卓端IM产品的网络链路保活技术实践》
2. 《融云技术分享：全面揭秘亿级IM消息的可靠投递机制》
3. 《融云技术分享：基于WebRTC的实时音视频首帧显示时间优化实践》
4. 《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》

3、超大群面临的技术挑战

与百人群、千人群相比，万人、甚至十万人超大群，大幅提升了群的触达人数，对于很多业务场景来说，好处不言而喻。

然而单群成员如此之大，给 IM 系统的流量冲击非常巨大，技术难度可想而之。我们先来分析一下超大群的技术挑战。

以一个万人群的模型为例：

• 1）如果群中有人发了消息，那么这条消息需要按照 1:9999 的比例进行分发投递，如果我们按照常规消息的处理流程，那么消息处理服务压力巨大；
• 2）消息量大的情况下，服务端向客户端直推消息的处理速度将会成为系统瓶颈，而一旦用户的消息下发队列造成了挤压，会影响到正常的消息分发，也会导致服务缓存使用量激增；
• 3）在微服务架构中，服务以及存储（DB，缓存）之间的 QPS 和网络流量也会急剧增高；
• 4）以群为单位的消息缓存，内存和存储开销较大（消息体的存储被放大了万倍）。

基于这些技术挑战，要想真正达成超大群的技术目标，势必要做特定的技术优化来应对。

4、一般群聊的消息投递模型

先来看看普通群聊的消息投递模型。

我们的普通群聊消息投递模型如下图所示：

如上图所示，当用户在普通群里发了一条消息后，投递路径是：

• 1）消息先到群组服务；
• 2）然后通过群组服务缓存的群关系，锁定这条消息最终需要分发的目标用户；
• 3）再根据一定的策略分发到消息服务上；
• 4）消息服务再根据用户的在线状态和消息状态来判断这条消息是直推、通知拉取还是转 Push，最终投递给目标用户。

普通群聊的消息投递，正像您期待的那样，基本上大家的实现手段都大差不差。然而对于万人群来说，这显然还不够。

下面来看看我们针对万人群聊消息投递的技术优化手段。

5、万人群聊消息投递优化手段1：控速

针对万人群的消息投递，我们的一个主要手段就是控速。

如上图所示。

首先：我们会根据服务器的核数来建立多个群消息分发队列，这些队列我们设置了不同的休眠时间以及不同的消费线程数。

通俗来讲，可以将队列这样划分为快、中、慢等队列。

其次：我们根据群成员数量的大小来将所有群映射到相应的队列中。

规则是：

• 1）小群映射到快队列中；
• 2）大群映射到相应的慢队列中。

然后：小群由于人数少，对服务的影响很小，所以服务利用快队列快速的将群消息分发出去，而大群群消息则利用慢队列的相对高延时来起到控速的作用。

6、万人群聊消息投递优化手段2：合并

在本文第3节中提到的万人群聊所面临的技术挑战，最主要的挑战其实就是消息进行扩散分发投递后，消息被克隆出N条，消息流量瞬间被放大。

举个例子：当一条群消息发送到 IM 服务器后，需要从群组服务投递给消息服务，如果每一个群成员都投递一次，并且投递的群消息内容是一致的话，那肯定会造成相应的资源浪费和服务压力。

那么针对这种情况，我们的解决方案就是进行消息合并投递。

原理就是：服务落点计算中我们使用的是一致性哈希，群成员落点相对固定，所以落点一致的群成员我们可以合并成一次请求进行投递，这样就大幅提高了投递效率同时减少了服务的压力。

下图是云信团队分享的万人群消息合并投递逻辑：

▲ 上图引用自《IM中的万人群聊技术方案实践总结》

如上图所示，云信团队的万人群消息合并投递方案是：按Link分组路由消息，同一Link上的全部群成员只需要路由一条消息即可。

7、十万、百万级的超大群处理方案

在实际群聊业务中，还有一种业务场景是超大规模群，这种群的群人数达到了数十万甚至上百万。

这种群如果按照上述的投投递方案，势必仍会造成消息节点的巨大压力。

比如我们有一个十万人的群，消息节点五台，消息服务处理消息的上限是一秒钟 4000 条，那每台消息节点大约会分到 2 万条群消息，这已大大超出了消息节点的处理能力。

所以为了避免上述问题，我们会将群成员上线超过3000的群识别为万人群、超级群，这种级别的群可以根据服务器数量和服务器配置相应做调整针对这种超级群会用特殊的队列来处理群消息的投递。

这个特殊的队列1秒钟往后端消息服务投递的消息数是消息服务处理上限的一半（留相应的能力处理其他消息），如果单台消息服务处理的 QPS 上限是 4000，那群组服务一秒往单台消息服务最多投递 2000 条。

8、写在最后

未来，我们也会针对群消息进行引用投递，对于大群里发的消息体比较大的消息，我们给群成员只分发和缓存消息的索引，比如 MessageID。等群成员真正拉取群消息时再从将消息组装好给客户端分发下去。这样做会节省分发的流量以及存储的空间。

随着互联网的发展，群组业务的模型和压力也在不停地扩展，后续可能还会遇到更多的挑战，当然也会不断迭代出更优的处理方式来应对。

附录：更多IM群聊技术文章

《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》

《如何保证IM实时消息的“时序性”与“一致性”？》

《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》

《IM群聊消息如此复杂，如何保证不丢不重？》

《微信后台团队：微信后台异步消息队列的优化升级实践分享》

《移动端IM中大规模群消息的推送如何保证效率、实时性？》

《现代IM系统中聊天消息的同步和存储方案探讨》

《关于IM即时通讯群聊消息的乱序问题讨论》

《IM群聊消息的已读回执功能该怎么实现？》

《IM群聊消息究竟是存1份(即扩散读)还是存多份(即扩散写)？》

《一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践》

《[技术脑洞] 如果把14亿中国人拉到一个微信群里技术上能实现吗？》

《IM群聊机制，除了循环去发消息还有什么方式？如何优化？》

《网易云信技术分享：IM中的万人群聊技术方案实践总结》

《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》

《IM群聊消息的已读未读功能在存储空间方面的实现思路探讨》

《直播系统聊天技术(一)：百万在线的美拍直播弹幕系统的实时推送技术实践之路》

《直播系统聊天技术(二)：阿里电商IM消息平台，在群聊、直播场景下的技术实践》

《直播系统聊天技术(三)：微信直播聊天室单房间1500万在线的消息架构演进之路》

《直播系统聊天技术(四)：百度直播的海量用户实时消息系统架构演进实践》

《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》

《融云IM技术分享：万人群聊消息投递方案的思考和实践》

>> 更多同类文章 ……

本文已同步发布于“即时通讯技术圈”公众号。

同步发布链接是：http://www.52im.net/thread-3687-1-1.html

1、引言

在IM客户端的使用场景中，基于本地数据的全文检索功能扮演着重要的角色，最常用的比如：查找聊天记录、联系人，就像下图这样。

▲ 微信的聊天记录查找功能

类似于IM中的聊天记录查找、联系人搜索这类功能，有了全文检索能力后，确实能大大提高内容查找的效率，不然，让用户手动翻找，确实降低了用户体验。

本文将具体来聊聊网易云信是如何实现IM客户端全文检索能力的，希望能带给你启发。

学习交流：

- 即时通讯/推送技术开发交流5群：215477170 [推荐]

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK

（本文同步发布于：http://www.52im.net/thread-3651-1-1.html）

2、关于作者

李宁：网易云信高级前端开发工程师，负责音视频 IM SDK 的应用开发、组件化开发及解决方案开发，对 React、PaaS 组件化设计、多平台的开发与编译有丰富的实战经验。

3、相关文章

IM客户端全文检索相关文章：

1. 《微信手机端的本地数据全文检索优化之路》
2. 《微信团队分享：微信移动端的全文检索多音字问题解决方案》

网易技术团队分享的其它文章：

1. 《网易视频云技术分享：音频处理与压缩技术快速入门》
2. 《网易云信实时视频直播在TCP数据传输层的一些优化思路》
3. 《网易云信技术分享：IM中的万人群聊技术方案实践总结》
4. 《Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？》
5. 《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》

4、什么是全文检索

所谓全文检索，就是要在大量内容中找到包含某个单词出现位置的技术。

在传统的关系型数据库中，只能通过 LIKE 条件查询来实现，这样有几个弊端：

• 1）无法使用数据库索引，需要遍历全表，性能较差；
• 2）搜索效果差，只能首尾位模糊匹配，无法实现复杂的搜索需求；
• 3）无法得到内容与搜索条件的相关性。

我们在 IM 的 iOS、安卓以及桌面端中都实现了基于 SQLite 等库的本地数据全文检索功能，但是在 Web 端和 Electron 上缺少了这部分功能。

因为在 Web 端，由于浏览器环境限制，能使用的本地存储数据库只有 IndexDB，暂不在讨论的范围内。但在 Electron 上，虽然也是内置了 Chromium 的内核，但是因为可以使用 Node.js 的能力，于是乎选择的范围就多了一些。本文内容我们具体以基于Electron的IM客户端为例，来讨论全文检索技术实现（技术思路是相通的，并不局限于具体什么端）。

PS：如果你不了解什么是Electron技术，读一下这篇《快速了解Electron：新一代基于Web的跨平台桌面技术》。

我们先来具体看下该如何实现全文检索。

要实现全文检索，离不开以下两个知识点：

• 1）倒排索引；
• 2）分词。

这两个技术是实现全文检索的技术以及难点，其实现的过程相对比较复杂，在聊全文索引的实现前，我们具体学习一下这两个技术的原理。

5、全文检索知识点1：倒排索引

先简单介绍下倒排索引，倒排索引的概念区别于正排索引：

• 1）正排索引：是以文档对象的唯一 ID 作为索引，以文档内容作为记录的结构；
• 2）倒排索引：是以文档内容中的单词作为索引，将包含该词的文档 ID 作为记录的结构。

以倒排索引库 search-index 举个实际的例子：

在我们的 IM 中，每条消息对象都有 idClient 作为唯一 ID，接下来我们输入「今天天气真好」，将其每个中文单独分词（分词的概念我们在下文会详细分享），于是输入变成了「今」、「天」、「天」、「气」、「真」、「好」。再通过 search-index 的 PUT 方法将其写入库中。

最后看下上述例子存储内容的结构：

如是图所示：可以看到倒排索引的结构，key 是分词后的单个中文、value 是包含该中文消息对象的 idClient 组成的数组。

当然：search-index 除了以上这些内容，还有一些其他内容，例如 Weight、Count 以及正排的数据等，这些是为了排序、分页、按字段搜索等功能而存在的，本文就不再细细展开了。

6、全文检索知识点2：分词

6.1 基本概念

分词就是将原先一条消息的内容，根据语义切分成多个单字或词句，考虑到中文分词的效果以及需要在 Node 上运行，我们选择了 Nodejieba 作为基础分词库。

以下是 jieba 分词的流程图：

以“去北京大学玩”为例，我们选择其中最为重要的几个模块分析一下。

6.2 加载词典

jieba 分词会在初始化时先加载词典，大致内容如下：

6.3 构建前缀词典

接下来会根据该词典构建前缀词典，结构如下：

其中：“北京大”作为“北京大学”的前缀，它的词频是0，这是为了便于后续构建 DAG 图。

6.4 构建 DAG 图

DAG 图是 Directed Acyclic Graph 的缩写，即有向无环图。

基于前缀词典，对输入的内容进行切分。

其中：

• 1）“去”没有前缀，因此只有一种切分方式；
• 2）对于“北”，则有“北”、“北京”、“北京大学”三种切分方式；
• 3）对于“京”，也只有一种切分方式；
• 4）对于“大”，有“大”、“大学”两种切分方式；
• 5）对于“学”和“玩”，依然只有一种切分方式。

如此，可以得到每个字作为前缀词的切分方式。

其 DAG 图如下图所示：

6.5 最大概率路径计算

以上 DAG 图的所有路径如下：

去/北/京/大/学/玩

去/北京/大/学/玩

去/北京/大学/玩

去/北京大学/玩

因为每个节点都是有权重（Weight）的，对于在前缀词典里的词语，它的权重就是它的词频。因此我们的问题就是想要求得一条最大路径，使得整个句子的权重最高。

这是一个典型的动态规划问题，首先我们确认下动态规划的两个条件。

1）重复子问题：

对于节点 i 和其可能存在的多个后继节点 j 和 k：

• 1）任意通过i到达j的路径的权重 = 该路径通过i的路径权重 + j的权重，即 R(i -> j) = R(i) + W(j)；
• 2）任意通过i到达k的路径的权重 = 该路径通过i的路径权重 + k的权重，即 R(i -> k) = R(i) + W(k)。

即对于拥有公共前驱节点 i 的 j 和 k，需要重复计算到达 i 路径的权重。

2）最优子结构：

设整个句子的最优路径为 Rmax，末端节点为 x，多个可能存在的前驱节点为 i、j、k。

得到公式如下：

Rmax = max(Rmaxi, Rmaxj, Rmaxk) + W(x)

于是问题变成了求解 Rmaxi、Rmaxj 以及 Rmaxk，子结构里的最优解即是全局最优解的一部分。

如上，最后计算得出最优路径为“去/北京大学/玩”。

6.6 HMM 隐式马尔科夫模型

对于未登陆词，jieba 分词采用 HMM（Hidden Markov Model 的缩写）模型进行分词。

它将分词问题视为一个序列标注问题，句子为观测序列，分词结果为状态序列。

jieba 分词作者在 issue 中提到，HMM 模型的参数基于网上能下载到的 1998 人民日报的切分语料，一个 MSR 语料以及自己收集的 TXT 小说、用 ICTCLAS 切分，最后用 Python 脚本统计词频而成。

该模型由一个五元组组成，并有两个基本假设。

五元组：

• 1）状态值集合；
• 2）观察值集合；
• 3）状态初始概率；
• 4）状态转移概率；
• 5）状态发射概率。

基本假设：

• 1）齐次性假设：即假设隐藏的马尔科夫链在任意时刻 t 的状态只依赖于其前一时刻 t-1 的状态，与其它时刻的状态及观测无关，也与时刻 t 无关；
• 2）观察值独立性假设：即假设任意时刻的观察值只与该时刻的马尔科夫链的状态有关，与其它观测和状态无关。

状态值集合即{ B: begin, E: end, M: middle, S: single }，表示每个字所处在句子中的位置，B 为开始位置，E 为结束位置，M 为中间位置，S 是单字成词。

观察值集合就是我们输入句子中每个字组成的集合。

状态初始概率表明句子中的第一个字属于 B、M、E、S 四种状态的概率，其中 E 和 M 的概率都是0，因为第一个字只可能 B 或者 S，这与实际相符。

状态转移概率表明从状态 1 转移到状态 2 的概率，满足齐次性假设，结构可以用一个嵌套的对象表示：

P = {

    B: {E: -0.510825623765990, M: -0.916290731874155},

    E: {B: -0.5897149736854513, S: -0.8085250474669937},

    M: {E: -0.33344856811948514, M: -1.2603623820268226},

    S: {B: -0.7211965654669841, S: -0.6658631448798212},

}

P['B']['E'] 表示从状态 B 转移到状态 E 的概率（结构中为概率的对数，方便计算）为 0.6，同理，P['B']['M'] 表示下一个状态是 M 的概率为 0.4，说明当一个字处于开头时，下一个字处于结尾的概率高于下一个字处于中间的概率，符合直觉，因为二个字的词比多个字的词要更常见。

状态发射概率表明当前状态，满足观察值独立性假设，结构同上，也可以用一个嵌套的对象表示：

P = {

    B: {'突': -2.70366861046, '肃': -10.2782270947, '适': -5.57547658034},

    M: {'要': -4.26625051239, '合': -2.1517176509, '成': -5.11354837278},

    S: {……},

    E: {……},

}

P['B']['突'] 的含义就是状态处于 B，观测的字是“突”的概率的对数值等于 -2.70366861046。

最后，通过 Viterbi 算法，输入观察值集合，将状态初始概率、状态转移概率、状态发射概率作为参数，输出状态值集合（即最大概率的分词结果）。关于 Viterbi 算法，本文不再详细展开，有兴趣的读者可以自行查阅。

7、技术实现

上节中介绍的全文检索这两块技术，是我们架构的技术核心。基于此，我们对IM 的 Electron 端技术架构做了改进。以下将详细介绍之。

7.1 架构图详解

考虑到全文检索只是 IM 中的一个功能，为了不影响其他 IM 的功能，并且能更快的迭代需求，所以采用了如下的架构方案。

架构图如下：

如上图所示，右边是之前的技术架构，底层存储库使用了 indexDB，上层有读写两个模块。

读写模块的具体作用是：

• 1）当用户主动发送消息、主动同步消息、主动删除消息以及收到消息的时候，会将消息对象同步到 indexDB；
• 2）当用户需要查询关键字的时候，会去 indexDB 中遍历所有的消息对象，再使用 indexOf 判断每一条消息对象是否包含所查询的关键字（类似 LIKE）。

那么，当数据量大的时候，查询的速度是非常缓慢的。

左边是加入了分词以及倒排索引数据库的新的架构方案，这个方案不会对之前的方案有任何影响，只是在之前的方案之前加了一层。

现在，读写模块的工作逻辑：

• 1）当用户主动发送消息、主动同步消息、主动删除消息以及收到消息的时候，会将每一条消息对象中的消息经过分词后同步到倒排索引数据库；
• 2）当用户需要查询关键字的时候，会先去倒排索引数据库中找出对应消息的 idClient，再根据 idClient 去 indexDB 中找出对应的消息对象返回给用户。

7.2 架构优点

该方案有以下4个优点：

• 1）速度快：通过 search-index 实现倒排索引，从而提升了搜索速度。
• 2）跨平台：因为 search-index 与 indexDB 都是基于 levelDB，因此 search-index 也支持浏览器环境，这样就为 Web 端实现全文检索提供了可能性；
• 3）独立性：倒排索引库与 IM 主业务库 indexDB 分离；
• 4）灵活性：全文检索以插件的形式接入。

针对上述第“3）”点：当 indexDB 写入数据时，会自动通知到倒排索引库的写模块，将消息内容分词后，插入到存储队列当中，最后依次插入到倒排索引数据库中。当需要全文检索时，通过倒排索引库的读模块，能快速找到对应关键字的消息对象的 idClient，根据 idClient 再去 indexDB 中找到消息对象并返回。

针对上述第“4）”点：它暴露出一个高阶函数，包裹 IM 并返回新的经过继承扩展的 IM，因为 JS 面向原型的机制，在新的 IM 中不存在的方法，会自动去原型链（即老的 IM）当中查找，因此，使得插件可以聚焦于自身方法的实现上，并且不需要关心 IM 的具体版本，并且插件支持自定义分词函数，满足不同用户不同分词需求的场景

7.3 使用效果

使用了如上架构后，经过我们的测试，在数据量 20W 的级别上，搜索时间从最开始的十几秒降到一秒内，搜索速度快了 20 倍左右。

8、本文小结

本文中，我们便基于 Nodejieba 和 search-index 在 Electron 上实现了IM聊天消息的全文检索，加快了聊天记录的搜索速度。

当然，后续我们还会针对以下方面做更多的优化，比如以下两点：

1）写入性能 ：在实际的使用中，发现当数据量大了以后，search-index 依赖的底层数据库 levelDB 会存在写入性能瓶颈，并且 CPU 和内存的消耗较大。经过调研，SQLite 的写入性能相对要好很多，从观测来看，写入速度只与数据量成正比，CPU 和内存也相对稳定，因此，后续可能会考虑用将 SQLite 编译成 Node 原生模块来替换 search-index。

2）可扩展性 ：目前对于业务逻辑的解耦还不够彻底。倒排索引库当中存储了某些业务字段。后续可以考虑倒排索引库只根据关键字查找消息对象的 idClient，将带业务属性的搜索放到 indexDB 中，将倒排索引库与主业务库彻底解耦。

以上，就是本文的全部分享，希望我的分享能对大家有所帮助。

附录：更多IM干货技术文章

《新手入门一篇就够：从零开发移动端IM》

《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》

《移动端IM中大规模群消息的推送如何保证效率、实时性？》

《移动端IM开发需要面对的技术问题》

《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》

《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》

《如何保证IM实时消息的“时序性”与“一致性”？》

《一个低成本确保IM消息时序的方法探讨》

《IM单聊和群聊中的在线状态同步应该用“推”还是“拉”？》

《IM群聊消息如此复杂，如何保证不丢不重？》

《谈谈移动端 IM 开发中登录请求的优化》

《移动端IM登录时拉取数据如何作到省流量？》

《浅谈移动端IM的多点登录和消息漫游原理》

《完全自已开发的IM该如何设计“失败重试”机制？》

《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》

《微信对网络影响的技术试验及分析（论文全文）》

《微信技术分享：微信的海量IM聊天消息序列号生成实践（算法原理篇）》

《自已开发IM有那么难吗？手把手教你自撸一个Andriod版简易IM (有源码)》

《融云技术分享：解密融云IM产品的聊天消息ID生成策略》

《适合新手：从零开发一个IM服务端（基于Netty，有完整源码）》

《拿起键盘就是干：跟我一起徒手开发一套分布式IM系统》

《适合新手：手把手教你用Go快速搭建高性能、可扩展的IM系统(有源码)》

《IM里“附近的人”功能实现原理是什么？如何高效率地实现它？》

《IM消息ID技术专题(一)：微信的海量IM聊天消息序列号生成实践（算法原理篇）》

《IM开发宝典：史上最全，微信各种功能参数和逻辑规则资料汇总》

《IM开发干货分享：我是如何解决大量离线消息导致客户端卡顿的》

《零基础IM开发入门(一)：什么是IM系统？》

《零基础IM开发入门(二)：什么是IM系统的实时性？》

《零基础IM开发入门(三)：什么是IM系统的可靠性？》

《零基础IM开发入门(四)：什么是IM系统的消息时序一致性？》

《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》

《IM扫码登录技术专题(三)：通俗易懂，IM扫码登录功能详细原理一篇就够》

《理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨》

《阿里技术分享：闲鱼IM基于Flutter的移动端跨端改造实践》

《融云技术分享：全面揭秘亿级IM消息的可靠投递机制》

《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》

《IM开发干货分享：有赞移动端IM的组件化SDK架构设计实践》

《IM开发干货分享：网易云信IM客户端的聊天消息全文检索技术实践》

>> 更多同类文章 ……

（本文同步发布于：http://www.52im.net/thread-3651-1-1.html）

本文由融云技术团队原创分享，原题“IM 消息同步机制全面解析”，为使文章更好理解，对内容进行了重新归纳和细节修订。

1、内容概述

即时通讯（IM）系统最基础、最重要的是消息的及时性与准确性，及时体现在延迟，准确则具体表现为不丢、不重、不乱序。

综合考虑业务场景、系统复杂度、网络流量、终端能耗等，我们的亿级分布式IM消息系统精心设计了消息收发机制，并不断打磨优化，形成了现在的消息可靠投递机制。

整体思路就是：

• 1）客户端、服务端共同配合，互相补充；
• 2）采用多重机制，从不同层面保障；
• 3）拆分上下行，分别处理。

本文根据融云亿级IM消息系统的技术实践，总结了分布式IM消息的可靠投递机制，希望能为你的IM开发和知识学习起到抛砖引玉的作用。

学习交流：

- 即时通讯/推送技术开发交流5群：215477170 [推荐]

- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK

（本文已同步发布于：http://www.52im.net/thread-3638-1-1.html）

2、推荐阅读

以下是相关文章汇总，有兴趣可以一并阅读：

《零基础IM开发入门(二)：什么是IM系统的实时性？》

《零基础IM开发入门(三)：什么是IM系统的可靠性？》

《零基础IM开发入门(四)：什么是IM系统的消息时序一致性？》

《IM消息送达保证机制实现(一)：保证在线实时消息的可靠投递》

《IM消息送达保证机制实现(二)：保证离线消息的可靠投递》

《IM开发干货分享：如何优雅的实现大量离线消息的可靠投递》

《理解IM消息“可靠性”和“一致性”问题，以及解决方案探讨》

《如何保证IM实时消息的“时序性”与“一致性”？》

《IM群聊消息如此复杂，如何保证不丢不重？》

《从客户端的角度来谈谈移动端IM的消息可靠性和送达机制》

《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》

《从新手到专家：如何设计一套亿级消息量的分布式IM系统》

《浅谈移动端IM的多点登录和消息漫游原理》

《完全自已开发的IM该如何设计“失败重试”机制？》

《IM开发干货分享：我是如何解决大量离线消息导致客户端卡顿的》

以下是融云技术团队分享的其它文章：

《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》

《融云技术分享：基于WebRTC的实时音视频首帧显示时间优化实践》

《融云技术分享：融云安卓端IM产品的网络链路保活技术实践》

《即时通讯云融云CTO的创业经验分享：技术创业，你真的准备好了？》

3、客户端与服务端消息交互整体原理

3.1 概述

一个完整的IM消息交互逻辑，通常会为两段：

• 1）消息上行段：即由消息发送者通过IM实时通道发送给服务端；
• 2）消息下行段：由服务端按照一定的策略送达给最终的消息接收人。

3.2 消息上行段

消息上行段主要就是依赖IM的实时通道将消息传递给服务端。

这个阶段的消息可靠投递，需要从协议层进行保证，协议层需要提供可靠、有序的双向字节流传输，我们是通过自研的通信协议 RMTP（即 RongCloud Message Transfer Protocol）实现的。

客户端与服务端之间使用长连接，基于 RMTP 协议传输数据。

RMTP协议交互示意图：

如上图所示，协议层通过 QoS、 ACK 等机制，保证IM消息上行段数据传输的可靠性。

3.3 消息下行段

经过总结，消息下行段主要有三种行为。

1）客户端主动拉取消息，主动拉取有两个触发方式：

• ① 拉取离线消息：与 IM 服务新建立连接成功，用于获取不在线的这段时间未收到的消息；
• ② 定时拉取消息：在客户端最后收到消息后启动定时器，比如 3-5 分钟执行一次。主要有两个目的，一个是用于防止因网络、中间设备等不确定因素引起的通知送达失败，服务端客户端状态不一致，一个是可通过本次请求，对业务层做状态机保活。

2）服务端主动-发送消息（直发消息）：

这是在线消息发送机制之一，简单理解为服务端将消息内容直接发送给客户端，适用于消息频率较低，并且持续交互，比如二人或者群内的正常交流讨论。

3）服务端主动-发送通知（通知拉取）：

这是在线消息发送机制之一，简单理解为服务端给客户端发送一个通知，通知包含时间戳等可作为排序索引的内容，客户端收到通知后，依据自身数据，对比通知内时间戳，发起拉取消息的流程。

这种场景适用于较多消息传递：比如某人有很多大规模的群，每个群内都有很多成员正在激烈讨论。通过通知拉取机制，可以有效的减少客户端服务端网络交互次数，并且对多条消息进行打包，提升有效数据载荷。既能保证时效，又能保证性能。

客户端服务端下行段消息交互示意图：

4、客户端与服务端消息交互具体实现

正如上节所言，我们将消息的交互流程进行了拆分：即拆分出上下行。

4.1 上行

在上行过程保证发送消息顺序，为了保证消息有序， 最好的方式是按照 userId 区分，然后使用时间戳排序。那么分布式部署情况下，将用户归属到固定的业务服务器上（PS：指的是同一账号的不同端固定连接到相同的业务服务器上），会使得上行排序变得更容易。同时归属到同一个服务器，在多端维护时也更容易。

客户端连接过程：

• 1）客户端通过 APP server ，获取到连接使用的 token；
• 2）客户端使用 token 通过导航服务，获取具体连接的 IM 接入服务器(CMP)，导航服务通过 userId 计算接入服务器，然后下发，使得某一客户端可以连接在同一台接入服务器(CMP)。

示意图如下：

小结一下就是：客户端发出消息后，通过接入服务，按照 userId 投递到指定消息服务器，生成消息 Id， 依据最后一条消息时间，确认更新当前消息的时间戳（如果存在相同时间戳则后延）。然后将时间戳，以及消息 Id，通过 Ack 返回给客户端 ; 然后对上行消息使用 userId + 时间戳进行缓存以及持久化存储，后续业务操作均使用此时间戳。

以上业务流程我们称为上行流程，上行过程存储的消息为发件箱消息。

PS：关于消息ID，需要补充说明一下：

我们采用全局唯一的消息 ID 生成策略。保证消息可通过 ID 进行识别，排重。消息ID的结构如下图所示。

如何实现分布式场景下唯一 ID 生成，具体请阅读：《IM消息ID技术专题(三)：解密融云IM产品的聊天消息ID生成策略》。

4.2 下行

消息节点在处理完上行流程后，消息按照目标用户投递到所在消息节点，进入下行流程。

下行过程，按照目标 userId 以及本消息在上行过程中生成的时间戳，计算是否需要更新时间戳（正向）。

如果需要更新则对时间戳进行加法操作，直到当前用户时间戳不重复。

如此处理后，目标用户的存储以及客户端接收到消息后的排重可以做到一致，并且可以做到同一个会话内的时间戳是有序的。从而保证同一个接收用户的消息不会出现乱序。

至此：我们已经介绍完了消息的下行交互过程，消息下行过程中的具体实现方式并不简单，以下将详细展开。

1）直发消息：

即服务端主动发送（给目标客户端）的消息：

• 1）客户端 SDK 依据本地存储的最新消息时间戳判断，用来做排序等逻辑；
• 2）对同一个用户直发消息1条，其他转通知。通知拉取时候客户端选择本地最新一条消息时间戳作为开始拉取时间；
• 3）在消息发送过程中，如果上一条消息发送流程未结束，下一条消息则不用直发(s_msg)，而是用通知(s_ntf)。

直发逻辑示意图：

2）通知拉取：

即服务端主动发送通知（给目标客户端）：

• 1）服务端在通知体中携带当前消息时间戳。投递给客户端；
• 2）客户端收到通知后，比对本地消息时间戳，选择是否发拉取消息信令；
• 3）服务端收到拉取消息信令后，以信令携带的时间戳为开始，查询出消息列表(200 条或者 5M)，并给客户端应答；
• 4）客户端收到后，给服务端 ack，服务端维护状态；
• 5）客户端拉取消息时使用的时间戳，是客户端本地最新一条消息的时间戳。

示意图：

在上图中，3-7 步可能需要循环多次，有以下考虑：

• a、客户端一次收到的消息过多，应答体积过于庞大，传输过程对网络质量要求更高， 因此按照数量以及消息体积分批次进行；
• b、一次拉取到的消息过多，客户端处理会占用大量资源，可能会有卡顿等，体验较差。

3）服务端直发消息与通知拉取切换逻辑：

主要涉及到的是状态机的更新。

下面示意图集成直发消息与通知拉取过程针对状态机的更新：

至此，消息收发的整个核心流程介绍完毕，余下的内容将介绍多端在线的消息同步处理。

5、多端在线的消息同步

多端按照消息的上下行两个阶段，同样区分为发送方多端同步以及接收方多端同步。

5.1 发送方多端同步

在前面客户端连接 IM 服务过程中（见本文 4.1节），我们已经将同一个用户的多个客户端汇聚在了同一台服务，那么维护一个 userId 的多端就会变得很简单。

具体逻辑是：

• 1）用户多个终端链接成功后，发送一条消息，这个消息到达 CMP(IM 接入服务) 后，CMP 做基础检查，然后获此用户的其他终端连接；
• 2）服务把客户端上行的消息，封装为服务端下行消息，直接投递给用户的其他客户端。这样完成了发送方的多端抄送，然后将这条消息投递到 IM 服务。进入正常发送投递流程。

针对上面的第2）点，发送方的多端同步没有经过 IM Server，这么做的好处是：

• 1）比较快速；
• 2）经过越少的服务节点，出问题的几率越小。

5.2 接收方多端同步

具体逻辑是：

• 1）IM 服务收到消息后，先判断接收方的投递范围，这个范围指的是接收方用户的哪些的终端要接收消息；
• 2）IM 服务将范围以及当前消息，发送到 CMP，CMP 依据范围，匹配接收方的终端，然后投递消息。

接收方多端消息同步范围的应用场景，一般都是针对所有终端。

但有一些特殊业务：比如我在 A 客户端上，控制另外某个端的状态，可能需要一些命令消息， 这时候需要这个作用范围，针对性的投递消息。

到此，我们分享完了有关 IM 消息核心处理流程，通过层层拆解逻辑，提供了可靠的消息投递机制。

附录：更多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年春节红包的技术实践》

《社交软件红包技术解密(十一)：解密微信红包随机算法(含代码实现)》

《即时通讯新手入门：一文读懂什么是Nginx？它能否实现IM的负载均衡？》

《即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》

《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》

《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》

《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》

《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》

《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》

《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》

《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》

《微信后台基于时间序的新一代海量数据存储架构的设计实践》

《IM开发基础知识补课(九)：想开发IM集群？先搞懂什么是RPC！》

《阿里技术分享：电商IM消息平台，在群聊、直播场景下的技术实践》

《一套亿级用户的IM架构技术干货(上篇)：整体架构、服务拆分等》

《一套亿级用户的IM架构技术干货(下篇)：可靠性、有序性、弱网优化等》

《从新手到专家：如何设计一套亿级消息量的分布式IM系统》

《企业微信的IM架构设计揭秘：消息模型、万人群、已读回执、消息撤回等》

《融云技术分享：全面揭秘亿级IM消息的可靠投递机制》

>> 更多同类文章 ……

本文已同步发布于“即时通讯技术圈”公众号。

▲ 本文在公众号上的链接是：点此进入。同步发布链接是：http://www.52im.net/thread-3638-1-1.html