背景
随着用户数的快速增长，闲鱼的IM也迎来了前所未有的挑战。多年的业务迭代，端侧IM的代码已经因为多年的迭代层次结构不足够清晰，之前消息一些隐藏起来的数据同步问题，也随着用户数的增大而被放大。
这里面的具体流程在于，后台需要同步到用户端侧的数据包，后台会根据数据包的业务类型划分成不同的数据域，数据包在对应域里面存在唯一且连续的编号，每一个数据包发送到端侧并且被成功消费后，端侧会记录当前每一个数据域已经同步过的版本编号，下一次数据同步就以本地数据域的编号开始，不断的同步到客户端。
当然用户不会一直在线等待消息，所以之前这里端侧采用了推拉结合的方式保证数据的同步。
在线时使用ACCS实时的将最新的数据内容推送到客户端。ACCS是淘宝无线向开发者提供全双工、低延时、高安全的通道服务。
离线启动后，根据本地的数据域编号，拉取不在线时候的数据差。
当数据获取出现黑洞（数据包Version不连续的状态）时，触发数据同步拉取。
分析
现存的一个同步策略是可以基本保障IM的数据同步的，但是也伴随着一些隐含的问题：
短时间密集数据推送时，会快速的触发多次数据域同步。域同步回来的数据如果存在问题，又会触发新一轮的同步，造成网络资源的浪费。冗余数据包/无效的数据内容会占用有效内容的处理资源，又对CPU和内存资源造成浪费。
Comments