共计 4273 个字符，预计需要花费 11 分钟才能阅读完成。
本文由阿里闲鱼技术团队书闲分享，原题“如何无效缩短闲鱼音讯解决时长”，有订正和改变。
1、引言
闲鱼技术团队围绕 IM 这个技术领域，曾经分享了好几篇实践性总结文章，本篇将要分享的是闲鱼 IM 零碎中在线和离线聊天音讯数据的同步机制上所遇到的一些问题，以及实践性的解决方案。
学习交换：
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2…
（本文已同步公布于：http://www.52im.net/thread-38…）
2、系列文章
本文是系列文章的第 7 篇，总目录如下：
《阿里 IM 技术分享(一)：企业级 IM 王者——钉钉在后端架构上的过人之处》
《阿里 IM 技术分享(二)：闲鱼 IM 基于 Flutter 的挪动端跨端革新实际》
《阿里 IM 技术分享(三)：闲鱼亿级 IM 音讯零碎的架构演进之路》
《阿里 IM 技术分享(四)：闲鱼亿级 IM 音讯零碎的牢靠投递优化实际》
《阿里 IM 技术分享(五)：闲鱼亿级 IM 音讯零碎的及时性优化实际》
《阿里 IM 技术分享(六)：闲鱼亿级 IM 音讯零碎的离线推送达到率优化》
《阿里 IM 技术分享(七)：闲鱼 IM 的在线、离线聊天数据同步机制优化实际》（* 本文）
3、问题背景
随着用户数的快速增长，闲鱼 IM 零碎也迎来了前所未有的挑战。
历经多年的业务迭代，客户端侧 IM 的代码曾经因为多年的迭代层次结构不足够清晰，之前一些暗藏起来的聊天数据同步问题，也随着用户数的增大而被放大。
这外面的具体流程在于：后盾须要同步到用户端侧的数据包，后盾会依据数据包的业务类型划分成不同的数据域，数据包在对应域外面存在惟一且间断的编号，每一个数据包发送到端侧并且被胜利生产后，端侧会记录以后每一个数据域曾经同步过的版本编号，下一次数据同步就以本地数据域的编号开始，一直的同步到客户端。
当然用户不会始终在线期待音讯，所以之前端侧采纳了推拉联合的形式保证数据的同步。
具体就是：
1）客户端在线时：应用 ACCS 实时的将最新的数据内容推送到客户端（ACCS 是淘宝无线向开发者提供全双工、低延时、高平安的通道服务）；
2）客户端从离线状态启动后：依据本地的数据域编号，拉取不在线时候的数据差；
3）当数据获取呈现黑洞时：触发数据同步拉取（“黑洞”即指数据包 Version 不间断的状态）。
4、问题剖析
以后的聊天数据同步策略的确是能够基本保障 IM 的数据同步的，然而也随同着一些隐含的问题。
这些隐含的问题次要有：
1）短时间密集数据推送时，会疾速的触发屡次数据域同步。域同步回来的数据如果存在问题，又会触发新一轮的同步，造成网络资源的节约。冗余数据包 / 有效的数据内容会占用无效内容的解决资源，又对 CPU 和内存资源造成节约；
2）数据域中的数据包客户端是否失常生产，服务端侧无感知，只能被动地依据以后数据域信息返回数据；
3）数据收取 / 音讯数据体解析 / 存储落库逻辑拆分不够清晰，无奈针对性的对某一层的代码拆分替换进行 ABTest。
针对上述问题，咱们对闲鱼 IM 进行了分层革新——即抽离数据同步层。这样优化，除了心愿当前这个数据的同步内容能够用在 IM 之外，也心愿随着稳定性的减少，赋能其余的业务场景。
接下来的内容，咱们重点来看下解决客户端侧闲鱼 IM 聊天数据同步问题的一些实际思路。
5、优化思路
5.1 分层拆分
对于服务端来说：业务侧产出数据包后，会拼接上以后的数据域信息，而后通过数据同步层将数据推送到端侧。
对于客户端来说：接管到数据包后，会依据以后的数据域信息，来确定须要生产数据包的业务方，确保数据包在数据域内残缺间断后，将数据体脱壳后交于业务侧生产，并且应答生产的情况。
数据同步层的抽取：把数据同步中的加壳、脱壳、校验、重试流程封装到一起，能够让下层业务只须要关怀本人须要监听的数据域信息，而后当这些数据域更新数据的时候，能够获取到这些数据进行生产，而不再须要关怀数据包是否残缺。
这样做的话：
1）业务侧只须要关怀业务侧对接的协定；
2）数据侧只须要关怀数据侧包装的协定；
3）网络层负责实在的数据传输。
整体的架构原理如下：
总结一下就是：
1）对齐数据层数据传输协定、形容以后数据包体数据域信息；
2）将音讯的解决 / 合并 / 落库抽离成数据消费者；
3）上下楼依赖抽象化，去除对于具体实现的依赖。
5.2 数据层构造模型
基于对于数据模型剥离和对当下遇见问题的解决方案规整，将数据同步层拆分为下图这样的架构。
具体的施行思路就是：
1）App 启动时建设 ACCS 长链接服务，保障推推送信道链接，并且依据以后本地数据域信息触发一次数据拉取；
2）数据消费者注册消费者信息和须要监听的数据域信息，这里是一对多的关系；
3）新的数据到达端侧后，将数据包放到指定的数据域的缓冲池，批量数据演绎完结后，从新登程数据的读取；
4）依据以后数据域优先级弹出最高优的数据包，判断数据域版本是否合乎消费者要求，合乎则将数据包脱壳后丢给消费者生产，不合乎则依据上一次正确的数据包的域信息触发增量的数据域同步拉取；
5）触发数据域同步拉取时，block 数据读取，此时通过 ACCS 触达的数据依旧会在持续归纳到指定的数据域队列中，期待数据域同步拉取后果，将数据包进行排序、去重，合并到对应的数据域队列中。而后从新激活数据读取；
6）数据包体被消费者正确生产后，更新域信息并且通过上行信道告知服务端曾经正确处理的数据域信息。
- 数据域同步协定：
Region 中携带的数据不用过多，但需将数据包的内容形容分明，具体是：
1）指标用户的 ID，用以确定指标数据包是否正确；
2）数据域 ID 和优先级信息；
3）以后数据包的域优先级版本。
- 排序策略：
针对于域数据演绎，无论是在写入数据的时候进行排序还是在读取的时候进行查找都须要进行一次排序的操作，工夫复杂度最优也是 O(logn)级别的。
在理论 coding 中发现因为在一个数据域外面，数据包的 Version 信息是间断惟一并且不存在断层的，上一个稳固生产的数据体的 Version 信息自增就是下一个数据包的 Version，所以这里采纳了以 Versio 为主键的 Map 存储，既升高了工夫复杂度，也使得惟一标识的数据包后到达端侧的包内容能够笼罩之前的包内容。
6、新的问题及解决策略
6.1 多数据起源和惟一数据生产的均衡
每当产生一条针对于以后用户的数据包：
1）如果以后 ACCS 长链接存在，就会通过 ACCS 将数据包推送到客户端；
2）如果 App 切换到后盾一段时间，或者间接被杀死，ACCS 链接断开，那么只能通过离线推送到用户的告诉面板。
所以：每当 App 切换到沉闷状态，都须要依据以后本地存储的数据域信息从后盾触发一次数据同步。
数据包触达到客户端侧的起源次要是 ACCS 长链接的推送和域同步时的拉取，然而数据包的生产是依据数据域的监听划分的惟一消费者，也就是同一时间内只能生产一个数据包。
在压力测试中：当后盾短时间内密集的将数据包通过 ACCS 推送到端侧时，端侧接管到的数据包并不有序，不间断的数据包域版本又会触发新的数据域同步，导致同样的一份数据包会通过两个不同的渠道屡次的触达到端侧，节约了不必要的流量。
当数据域同步时：这个工夫节点产生的新数据包也会推送到端侧，数据体无效，并且须要被正确的生产。
针对上述这些问题的解决策略：
即在数据生产和数据获取两头装载一个数据中间层，当触发数据域同步的时候 block 数据的读取并且 ACCS 推送下来的数据包会被寄存在一个数据的中转站外面，当数据域同步拉取的数据回来后，对数据进行合并后再重启数据读取流程。
6.2 数据域优先级
须要推送到客户端侧的数据包，依据业务的不同优先级也有不同的划分。
用户和用户的聊天产生的数据包会比经营类的音讯的数据包优先级要高一些，所以要当多优先级的数据包疾速的到达端侧时，高优先级数据域的数据包须要被优先生产，而数据域的优先级也是须要动静调整，须要一直变换的优先级策略。
针对这个问题的解决策略：
不同的数据域，产生不同的数据队列，高优队列外面的数据包会被优先读取生产。
每一个数据包体中带回的数据域信息，都能够标注以后的数据域优先级，当数据域优先级发生变化的时候，调整数据包生产优先级策略。
7、优化后的成果
除去构造上分层梳理，使得数据同步层和依赖的服务内容可便捷解耦 / 每一个环节可插拔之外，数据同步中对于音讯生产时长 / 流量节俭，压力测试场景下优化成果更加显著。
在“500ms 内 100 条全乱序数据包推送”压力测试场景下：
1）音讯解决时长（接管 - 上屏）缩短 31%；
2）流量损耗（最终拉取到端侧数据包累积大小）升高 35%。
8、后续的优化打算
8.1 数据同步层能力晋升
数据同步侧的指标，既要保障数据包残缺的达到端侧，又要在保障稳定性的前提下尽可能的缩小数据的拉取，使得每一次数据的获取都无效。
后续数据同步层会着手于无效数据率和达到率进行更进一步的优化。
针对不同的场景，动静智能调整数据同步的优先级策略。
阻塞式长链接推送，保障同一时间只存在推模式或者拉模式，进一步缩小冗余数据包的推送。
8.2 IM 端侧整体架构降级
降级数据同步层策略次要还是要晋升 IM 的能力，将数据同步分层后，接下来就是将音讯的解决流程化，对每一个流程都可监控可回溯，晋升 IM 数据包的正确解析存储和落库率。
细化一下就是：
1）在数据起源侧剥来到后，后续对 IM 的整改也会逐渐的将音讯的解决分层剥离；
2）音讯解决要害节点的流程式上报、建设残缺的监控体系，让问题发现先于用户舆情；
3）音讯完整性的动静自检，最小化数据弥补补全。
9、参考资料
[1] IM 单聊和群聊中的在线状态同步应该用“推”还是“拉”？
[2] IM 群聊音讯如此简单，如何保障不丢不重？
[3] 一套高可用、易伸缩、高并发的 IM 群聊、单聊架构方案设计实际
[4] 一套亿级用户的 IM 架构技术干货(下篇)：可靠性、有序性、弱网优化等
[5] 从老手到专家：如何设计一套亿级音讯量的分布式 IM 零碎
[6] 融云技术分享：全面揭秘亿级 IM 音讯的牢靠投递机制
[7] 挪动端 IM 中大规模群音讯的推送如何保障效率、实时性？
[8] 古代 IM 零碎中聊天音讯的同步和存储计划探讨
[9] 新手入门一篇就够：从零开发挪动端 IM
[10] IM 音讯送达保障机制实现(一)：保障在线实时音讯的牢靠投递
[11] IM 音讯送达保障机制实现(二)：保障离线音讯的牢靠投递
[12] 零根底 IM 开发入门(四)：什么是 IM 零碎的音讯时序一致性？
[13] IM 开发干货分享：我是如何解决大量离线音讯导致客户端卡顿的
（本文已同步公布于：http://www.52im.net/thread-38…）
