本文由融云技术团队原创分享，原题“IM 消息同步机制全面解析”，为使文章更好理解，对内容进行了重新归纳和细节修订。
1、内容概述
即时通讯（IM）系统最基础、最重要的是消息的及时性与准确性，及时体现在延迟，准确则具体表现为不丢、不重、不乱序。
综合考虑业务场景、系统复杂度、网络流量、终端能耗等，我们的亿级分布式IM消息系统精心设计了消息收发机制，并不断打磨优化，形成了现在的消息可靠投递机制。
整体思路就是：
1）客户端、服务端共同配合，互相补充；
2）采用多重机制，从不同层面保障；
3）拆分上下行，分别处理。
本文根据融云亿级IM消息系统的技术实践，总结了分布式IM消息的可靠投递机制，希望能为你的IM开发和知识学习起到抛砖引玉的作用。
（本文已同步发布于：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 消息核心处理流程，通过层层拆解逻辑，提供了可靠的消息投递机制。
