共计 5980 个字符，预计需要花费 15 分钟才能阅读完成。
本文由融云技术团队原创分享，原题“IM 音讯同步机制全面解析”，为使文章更好了解，对内容进行了从新演绎和细节订正。
1、内容概述
即时通讯（IM）零碎最根底、最重要的是音讯的及时性与准确性，及时体现在提早，精确则具体表现为不丢、不重、不乱序。
综合思考业务场景、零碎复杂度、网络流量、终端能耗等，咱们的亿级分布式 IM 音讯零碎精心设计了音讯收发机制，并一直打磨优化，造成了当初的音讯牢靠投递机制。
整体思路就是：
1）客户端、服务端独特配合，相互补充；
2）采纳多重机制，从不同层面保障；
3）拆分上下行，别离解决。
本文依据融云亿级 IM 音讯零碎的技术实际，总结了分布式 IM 音讯的牢靠投递机制，心愿能为你的 IM 开发和常识学习起到抛砖引玉的作用。
学习交换：
- 即时通讯 / 推送技术开发交换 5 群：215477170 [举荐]
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2…
（本文已同步公布于：http://www.52im.net/thread-36…）
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-36…
