阿里IM技术分享(七)：闲鱼IM的在线、离线聊天数据同步机制优化实践

本文由阿里闲鱼技术团队书闲分享，原题“如何有效缩短闲鱼消息处理时长”，有修订和改动，感谢作者的分享。

1、引言

闲鱼技术团队围绕IM这个技术范畴，已经分享了好几篇实践性总结文章，本篇将要分享的是闲鱼IM系统中在线和离线聊天消息数据的同步机制上所遇到的一些问题，以及实践性的解决方案。

学习交流：

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

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

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

2、系列文章

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

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存储，既降低了时间复杂度，也使得唯一标识的数据包后抵达端侧的包内容可以覆盖之前的包内容。