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

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

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

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

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

　　《零基础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、客户端与服务端消息交互整体原理

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

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

　　① 拉取离线消息：与 IM 服务新建立连接成功，用于获取不在线的这段时间未收到的消息；

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

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

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

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

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

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

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

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

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

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

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

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

　　1）客户端 SDK 依据本地存储的最新消息时间戳判断，用来做排序等逻辑；

　　2）对同一个用户直发消息1条，其他转通知。通知拉取时候客户端选择本地最新一条消息时间戳作为开始拉取时间；

　　3）在消息发送过程中，如果上一条消息发送流程未结束，下一条消息则不用直发(s_msg)，而是用通知(s_ntf)。

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

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

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

　　1）用户多个终端链接成功后，发送一条消息，这个消息到达 CMP(IM 接入服务) 后，CMP 做基础检查，然后获此用户的其他终端连接；

　　2）服务把客户端上行的消息，封装为服务端下行消息，直接投递给用户的其他客户端。这样完成了发送方的多端抄送，然后将这条消息投递到 IM 服务。进入正常发送投递流程。

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

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

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