24小时热线电话 0898-08980898
发布日期：2022-09-06 00:14:44 点击次数：
本文由阿里闲鱼技术团队书闲分享，原题“如何有效缩短闲鱼消息处理时长”，有修订和改动，感谢作者的分享。
闲鱼技术团队围绕IM这个技术范畴，已经分享了好几篇实践性总结文章，本篇将要分享的是闲鱼IM系统中在线和离线聊天消息数据的同步机制上所遇到的一些问题，以及实践性的解决方案。
历经多年的业务迭代，客户端侧IM的代码已经因为多年的迭代层次结构不足够清晰，之前一些隐藏起来的聊天数据同步问题，也随着用户数的增大而被放大。
这里面的具体流程在于：后台需要同步到用户端侧的数据包，后台会根据数据包的业务类型划分成不同的数据域，数据包在对应域里面存在唯一且连续的编号，每一个数据包发送到端侧并且被成功消费后，端侧会记录当前每一个数据域已经同步过的版本编号IM电竞APP，下一次数据同步就以本地数据域的编号开始，不断的同步到客户端。
当然用户不会一直在线等待消息，所以之前端侧采用了推拉结合的方式保证数据的同步。
1）客户端在线时：使用ACCS实时的将最新的数据内容推送到客户端（ACCS是淘宝无线向开发者提供全双工、低延时、高安全的通道服务）；
2）客户端从离线状态启动后：根据本地的数据域编号，拉取不在线）当数据获取出现黑洞时：触发数据同步拉取（“黑洞”即指数据包Version不连续的状态）IM电竞APP。
当前的聊天数据同步策略确实是可以基本保障IM的数据同步的，但是也伴随着一些隐含的问题。
1）短时间密集数据推送时，会快速的触发多次数据域同步。域同步回来的数据如果存在问题，又会触发新一轮的同步，造成网络资源的浪费。冗余数据包/无效的数据内容会占用有效内容的处理资源，又对CPU和内存资源造成浪费；
2）数据域中的数据包客户端是否正常消费，服务端侧无感知，只能被动地根据当前数据域信息返回数据；
3）数据收取/消息数据体解析/存储落库逻辑拆分不够清晰，无法针对性的对某一层的代码拆分替换进行ABTest。
针对上述问题，我们对闲鱼IM进行了分层改造——即抽离数据同步层。这样优化，除了希望以后这个数据的同步内容可以用在IM之外，也希望随着稳定性的增加，赋能其他的业务场景。
接下来的内容，我们重点来看下解决客户端侧闲鱼IM聊天数据同步问题的一些实践思路。
业务侧产出数据包后，会拼接上当前的数据域信息，然后通过数据同步层将数据推送到端侧。
接收到数据包后，会根据当前的数据域信息，来确定需要消费数据包的业务方，确保数据包在数据域内完整连续后，将数据体脱壳后交于业务侧消费，并且应答消费的状况。
把数据同步中的加壳、IM电竞APP脱壳、校验、重试流程封装到一起，可以让上层业务只需要关心自己需要监听的数据域信息，然后当这些数据域更新数据的时候，可以获取到这些数据进行消费，而不再需要关心数据包是否完整。
2）数据消费者注册消费者信息和需要监听的数据域信息，这里是一对多的关系；
4）根据当前数据域优先级弹出最高优的数据包，判断数据域版本是否符合消费者要求，符合则将数据包脱壳后丢给消费者消费，不符合则根据上一次正确的数据包的域信息触发增量的数据域同步拉取；
5）触发数据域同步拉取时，block数据读取，此时通过ACCS触达的数据依旧会在继续归纳到指定的数据域队列中，等待数据域同步拉取结果，将数据包进行排序、去重，合并到对应的数据域队列中。然后重新激活数据读取；
6）数据包体被消费者正确消费后，更新域信息并且通过上行信道告知服务端已经正确处理的数据域信息。
Region中携带的数据不必过多，但需将数据包的内容描述清楚，具体是：
在实际coding中发现由于在一个数据域里面，数据包的Version信息是连续唯一并且不存在断层的，上一个稳定消费的数据体的Version信息自增就是下一个数据包的Version，所以这里采用了以Versio为主键的Map存储，既降低了时间复杂度，也使得唯一标识的数据包后抵达端侧的包内容可以覆盖之前的包内容。
2）如果App切换到后台一段时间，或者直接被杀死，ACCS链接断开，那么只能通过离线推送到用户的通知面板。
在压力测试中：当后台短时间内密集的将数据包通过ACCS推送到端侧时，端侧接收到的数据包并不有序，不连续的数据包域版本又会触发新的数据域同步，导致同样的一份数据包会通过两个不同的渠道多次的触达到端侧，浪费了不必要的流量。
即在数据消费和数据获取中间装载一个数据中间层，当触发数据域同步的时候block数据的读取并且ACCS推送下来的数据包会被存放在一个数据的中转站里面，当数据域同步拉取的数据回来后，对数据进行合并后再重启数据读取流程。
2）消息处理关键节点的流程式上报、建立完整的监控体系，让问题发现先于用户舆情；
