默认
打赏 发表评论 11
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
阿里IM技术分享(四):闲鱼亿级IM消息系统的可靠投递优化实践
微信扫一扫关注!

本文由阿里闲鱼技术团队景松分享,原题“到达率99.9%:闲鱼消息在高速上换引擎(集大成)”,即时通讯网有修订和改动,感谢作者的分享。


1、引言


在2020年年初的时候接手了闲鱼的IM即时消息系统,当时的消息存在各种问题,网上的用户舆情也是接连不断。

典型的问题,比如:

  • 1)“聊天消息经常丢失”;
  • 2)“消息用户头像乱了”;
  • 3)“订单状态不对”(相信现在看文章的你还在吐槽闲鱼的消息)。

所以闲鱼的即时消息系统稳定性、可靠性是一个亟待解决的问题。

我们调研了集团内的一些解决方案,例如钉钉的IMPass。如果贸然直接迁移,技术成本和风险都是比较大,包括服务端数据需要双写、新老版本兼容等。

那么基于闲鱼现有的即时消息系统架构和技术体系,如何来优化它的消息稳定性、可靠性?应该从哪里开始治理?当前系统现状到底是什么样?如何客观进行衡量?希望本文能让大家看到一个不一样的闲鱼即时消息系统。

PS:如果您对IM消息可靠性还没有概念,建议先阅读这篇入门文章《零基础IM开发入门(三):什么是IM系统的可靠性?》。

cover-opti2.png

本文已同步发布于“即时通讯技术圈”公众号,欢迎关注。公众号上的链接是:点此进入

2、系列文章


本文是系列文章的第4篇,总目录如下:


3、行业方案


经过查阅网上分享的主流消息可靠投递技术方案,我进行了简单总结。

通常IM消息的投递链路大致分为三步:

  • 1)发送者发送;
  • 2)服务端接收然后落库;
  • 3)服务端通知接收端。

特别是移动端的网络环境比较复杂:

  • 1)可能你发着消息,网络突然断掉了;
  • 2)可能消息正在发送中,网络突然好了,需要重发。

技术原理图大如下:
1.png

PS:可能很多人对移动网络的复杂性没有个系统的认知,以下文章有必要系统阅读:


那么,在如此复杂的网络环境下,是如何稳定可靠的进行IM消息投递的?

对于发送者来说,它不知道消息是否有送达,要想做到确定送达,就需要加一个响应机制。

这个机制类似于下面的响应逻辑:

  • 1)发送者发送了一条消息“Hello”,进入等待状态;
  • 2)接收者收到这条消息“Hello”,然后告诉发送者说我已经收到这条消息了的确认信息;
  • 3)发送者接收到确认信息后,这个流程就算完成了,否则会重试。

上面流程看似简单,关键是中间有个服务端转发过程,问题就在于谁来回这个确认信息,以及什么时候回这个确认信息。

网上查到比较多的是如下一个消息必达模型:
2.png

各报文类型解释如下:
2-2.png

如上面两图所示,发送流程是:

  • 1)A向IM-server发送一个消息请求包,即msg:R1;
  • 2)IM-server在成功处理后,回复A一个消息响应包,即msg:A1;
  • 3)如果此时B在线,则IM-server主动向B发送一个消息通知包,即msg:N1(当然,如果B不在线,则消息会存储离线)。

如上面两图所示,接收流程是:

  • 1)B向IM-server发送一个ack请求包,即ack:R2;
  • 2)IM-server在成功处理后,回复B一个ack响应包,即ack:A2;
  • 3)IM-server主动向A发送一个ack通知包,即ack:N2。

正如上述模型所示:一个可靠的消息投递机制就是靠的6条报文来保证的,中间任何一个环节出错,都可以基于这个request-ack机制来判定是否出错并重试。

我们最终采用的方案也正是参考了上面这个模型,客户端发送的逻辑是直接基于http的所以暂时不用做重试,主要是在服务端往客户端推送的时候,会加上重试的逻辑。

限于篇幅,本文就不详细展开,有兴趣可以系统学习以下几篇:


4、当前面临的具体问题


4.1概述


在解决消息可靠投递这个问题之前,我们肯定首先应该搞清楚当前面临的具体问题到底有哪些。

然而在接手这套即时消息系统时,并没有相关的准确数据可供参考,所以当前第一步还是要对这套消息系统做一个完整的排查,于是我们对消息做了全链路埋点。

具体的埋点环节如下:
3.png

基于消息的整个链路,我们梳理出来了几个关键的指标:

  • 1)发送成功率;
  • 2)消息到达率;
  • 3)客户端落库率。

这次整个数据的统计都是基于埋点来做的,但在埋点的过程中发现了一个很大的问题:当前这套即时消息系统没有一个全局唯一的消息ID。这导致在全链路埋点的过程中,无法唯一确定这条消息的生命周期。

4.2消息唯一性问题


4.png

如上图所示,当前的消息是通过3个变量来确定唯一性的:

  • 1)SessionID: 当前会话的ID;
  • 2)SeqID:用户当前本地发送的消息序号,服务端是不关心此数据,完全是透传;
  • 3)Version:这个比较重要,是消息在当前会话中的序号,已服务端为准,但是客户端也会生成一个假的version。

以上图为例:当A和B同时发送消息的时候,都会在本地生成如上几个关键信息,当A发送的消息(黄色)首先到达服务端,因为前面没有其他version的消息,所以会将原数据返回给A,客户端A接收到消息的时候,再跟本地的消息做合并,只会保留一条消息。同时服务端也会将此消息发送给B,因为B本地也有一个version=1的消息,所以服务端过来的消息就会被过滤掉,这就出现消息丢失的问题。

当B发送消息到达服务端后,因为已经有version=1的消息,所以服务端会将B的消息version递增,此时消息的version=2。这条消息发送给A,和本地消息可以正常合并。但是当此消息返回给B的时候,和本地的消息合并,会出现2条一样的消息,出现消息重复,这也是为什么闲鱼之前总是出现消息丢失和消息重复最主要的原因。

4.3消息推送逻辑问题


当前消息的推送逻辑也存在很大的问题,发送端因为使用http请求,发送的消息内容基本不会出问题,问题是出现在服务端给另外一端推送的时候。

如下图所示:
5.png

如上图所示:服务端在给客户端推送的时候,会先判断此时客户端是否在线,如果在线才会推送,如果不在线就会推离线消息。

这个做法就非常的简单粗暴:长连接的状态如果不稳定,导致客户端真实状态和服务端的存储状态不一致,就导致消息不会推送到端上。

4.4客户端逻辑问题


除了以上跟服务端有关系外,还有一类问题是客户端本身设计的问题。

可以归结为以下几种情况:

  • 1)多线程问题:反馈消息列表页面会出现布局错乱,本地数据还没有完全初始化好,就开始渲染界面;
  • 2)未读数和小红点的计数不准:本地的显示数据和数据库存储的不一致;
  • 3)消息合并问题:本地在合并消息的时候,是分段合并的,不能保证消息的连续性和唯一性。

诸如以上的几种情况,我们首先是对客户端的代码做了梳理与重构。

架构如下图所示:
6.png

5、我们的优化工作1:升级通心核心


解决问题第一步就是解决当前消息系统唯一性的问题。

我们也调研了钉钉的方案,钉钉是服务端全局维护消息的唯一ID,考虑到闲鱼即时消息系统的历史包袱,我们这边采用UUID作为消息的唯一ID,这样就可以在消息链路埋点以及去重上得到很大的改善。

5.1解决消息唯一性


在新版本的APP上面,客户端会生成一个uuid,对于老版本无法生成的情况,服务端也会补充上相关信息。

7.png

消息的ID类似于 a1a3ffa118834033ac7a8b8353b7c6d9,客户端在接收到消息后,会先根据MessageID来去重,然后基于Timestamp排序就可以了,虽然客户端的时间可能不一样,但是重复的概率还是比较小。

以iOS端为例,代码大致如下:
- (void)combileMessages:(NSArray<PMessage*>*)messages {
    ...
    
    // 1. 根据消息MessageId进行去重
    NSMutableDictionary *messageMaps = [self containerMessageMap];
    for (PMessage *message in msgs) {
        [messageMaps setObject:message forKey:message.messageId];
    }
    
    // 2. 消息合并后排序
    NSMutableArray *tempMsgs = [NSMutableArray array];
    [tempMsgs addObjectsFromArray:messageMaps.allValues];
    [tempMsgs sortUsingComparator:^NSComparisonResult(PMessage * _Nonnull obj1, PMessage * _Nonnull obj2) {
        // 根据消息的timestamp进行排序
        return obj1.timestamp > obj2.timestamp;
    }];
    
    ...
}

5.2实现消息重发、断线重连机制


8.png

基于本文“3、行业方案”一节中的重发重连模型,我们完善了服务端的消息重发的逻辑、客户端完善了断线重连的逻辑。

具体措施是:

  • 1)客户端会定时检测ACCS长连接是否联通;
  • 2)服务端会检测设备是否在线,如果在线会推送消息,并会有超时等待;
  • 3)客户端接收到消息之后,会返回一个Ack。

5.3优化数据同步逻辑


重发重连解决的基础网络层的问题,接下来就要看下业务层的问题。

现有消息系统中,很多复杂情况是通过在业务层增加兼容代码来解决的,消息的数据同步就是一个很典型的场景。

在完善数据同步的逻辑之前,我们也调研过钉钉的一整套数据同步方案,他们主要是由服务端来保证的,背后有一个稳定的长连接保证。

钉钉的数据同步方案大致流程如下:
9.png

我们的服务端暂时还没有这种能力,所以闲鱼这边只能从客户端来控制数据同步的逻辑。

数据同步的方式包括:

  • 1)拉取会话;
  • 2)拉取消息;
  • 3)推送消息等。

因为涉及到的场景比较复杂,之前有个场景就是推送会触发增量同步,如果推送过多的话,会同时触发多次网络请求,为了解决这个问题,我们也做了相关的推拉队列隔离。

10.png

客户端控制的策略就是如果在拉取的话,会先将push过来的消息加到缓存队列里面,等拉取的结果回来,会再跟本地缓存的逻辑做合并,这样就可以避免多次网络请求的问题。

5.4客户端数据模型优化


客户端在数据组织形式上,主要分2中:会话和消息,会话又分为:虚拟节点、会话节点和文件夹节点。

11.png

在客户端会构建上图一样的树,这棵树主要保存的是会话显示的相关信息,比如未读数、红点以及最新消息摘要,子节点更新,会顺带更新到父节点,构建树的过程也是已读和未读数更新的过程。

其中比较复杂的场景是闲鱼情报社,这个其实是一个文件夹节点,它包含了很多个子的会话,这就决定了他的消息排序、红点计数以及消息摘要的更新逻辑会更复杂,服务端告知客户端子会话的列表,然后客户端再去拼接这些数据模型。

5.5服务端存储模型优化


12.jpg

在前述内容中,我大概讲了客户端的请求逻辑,即历史消息会分为增量和全量域同步。

这个域其实是服务端的一层概念,本质上就是用户消息的一层缓存,消息过来之后会暂存在缓存中,加速消息读取。

但是这个设计也存在一个缺陷:就是域环是有长度的,最多保存256条,当用户的消息数多于256条,只能从数据库中读取。

关于服务端的存储方式,我们也调研过钉钉的方案——是写扩散,优点就是可以很好地对每位用户的消息做定制化,缺点就是存储量很很大。

我们的这套解决方案,应该是介于读扩散和写扩散之间的一种解决方案。这个设计方式不仅使客户端逻辑复杂,服务端的数据读取速度也会比较慢,后续这块也可以做优化。

6、我们的优化工作2:增加质量监控体系


在做客户端和服务端的全链路改造的同时,我们也对消息线上的行为做了监控和排查的逻辑。

6.1全链路排查


13.png

全链路排查是基于用户的实时行为日志,客户端的埋点通过集团实时处理引擎Flink,将数据清洗到SLS里面。

用户的行为包括:

  • 1)消息引擎对消息的处理;
  • 2)用户的点击/访问页面的行为;
  • 3)用户的网络请求。

服务端侧会有一些长连接推送以及重试的日志,也会清洗到SLS,这样就组成了从服务端到客户端全链路的排查的方案。

6.2对账系统


当然为了验证消息的准确性,我们还做了对账系统:
14.png

在用户离开会话的时候,我们会统计当前会话一定数量的消息,生成一个md5的校验码,上报到服务端。服务端拿到这个校验码之后再判定是否消息是正确的。

经过抽样数据验证,消息的准确性基本都在99.99%。

7、数据指标统计方法优化


我们在统计消息的关键指标时,遇到点问题:之前我们是用用户埋点来统计的,发现会有3%~5%的数据差。

后来我们采用抽样实时上报的数据来计算数据指标:

消息到达率 = 客户端实际收到的消息量 / 客户端应该收到的消息量


客户端实际收到的消息的定义为“消息落库才算是”。

该指标不区分离线在线,取用户当日最后一次更新设备时间,理论上当天且在此时间之前下发的消息都应该收到。

15.png

经过前述优化工作,我们最新版本的消息到达率已经基本达到99.9%,从舆情上来看,反馈丢消息的也确实少了很多。

8、未来规划


整体看来,经过一年的优化治理,我们的即时消息系统各项指标在慢慢变好。

但还是存在一些待优化的方面:

  • 1)消息的安全性不足:容易被黑产利用,借助消息发送一些违规的内容;
  • 2)消息的扩展性较弱:增加一些卡片或者能力就要发版,缺少了动态化和扩展的能力。
  • 3)底层的伸缩性不足:现在底层协议比较难扩展,后续还是要规范一下协议。

从业务角度看,消息应该是一个横向支撑的工具性或者平台型的产品,且可以快速对接二方和三方的快速对接。

接下来,我们会持续关注消息相关的用户舆情,希望闲鱼即时消息系统能帮助用户更好的完成业务交易。

附录:更多相关文章


[1] 更多阿里巴巴的技术资源:

阿里钉钉技术分享:企业级IM王者——钉钉在后端架构上的过人之处
现代IM系统中聊天消息的同步和存储方案探讨
阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史
阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路
来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享
钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT) [附件下载]
阿里技术结晶:《阿里巴巴Java开发手册(规约)-华山版》[附件下载]
重磅发布:《阿里巴巴Android开发手册(规约)》[附件下载]
作者谈《阿里巴巴Java开发手册(规约)》背后的故事
《阿里巴巴Android开发手册(规约)》背后的故事
干了这碗鸡汤:从理发店小弟到阿里P10技术大牛
揭秘阿里、腾讯、华为、百度的职级和薪酬体系
淘宝技术分享:手淘亿级移动端接入层网关的技术演进之路
难得干货,揭秘支付宝的2维码扫码技术优化实践之路
淘宝直播技术干货:高清、低延时的实时视频直播技术解密
阿里技术分享:电商IM消息平台,在群聊、直播场景下的技术实践
阿里技术分享:闲鱼IM基于Flutter的移动端跨端改造实践
阿里IM技术分享(三):闲鱼亿级IM消息系统的架构演进之路
阿里IM技术分享(四):闲鱼亿级IM消息系统的可靠投递优化实践

[2] 有关IM架构设计的文章:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信后台基于时间序的海量数据冷热分级架构设计实践
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
移动端IM中大规模群消息的推送如何保证效率、实时性?
现代IM系统中聊天消息的同步和存储方案探讨
微信朋友圈千亿访问量背后的技术挑战和实践总结
子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践
微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)
一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践
社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等
从游击队到正规军(一):马蜂窝旅游网的IM系统架构演进之路
从游击队到正规军(二):马蜂窝旅游网的IM客户端架构演进和实践总结
从游击队到正规军(三):基于Go的马蜂窝旅游网分布式IM系统技术实践
瓜子IM智能客服系统的数据架构设计(整理自现场演讲,有配套PPT)
IM开发基础知识补课(九):想开发IM集群?先搞懂什么是RPC!
阿里技术分享:电商IM消息平台,在群聊、直播场景下的技术实践
一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等
一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等
从新手到专家:如何设计一套亿级消息量的分布式IM系统
企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等
融云技术分享:全面揭秘亿级IM消息的可靠投递机制
IM开发技术学习:揭秘微信朋友圈这种信息推流背后的系统设计
阿里IM技术分享(三):闲鱼亿级IM消息系统的架构演进之路
>> 更多同类文章 ……

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:求教IM的app端消息id生成问题,是服务端生成还是客户端生成?下一篇:求教大家做im的心得,通过socket发送消息到redis订阅发布行不行

本帖已收录至以下技术专辑

推荐方案
评论 11
文章信息量较多,阅读后产生的疑问也比较多,望Jack Jiang大佬不吝赐教:

引用:客户端发送的逻辑是直接基于http的所以暂时不用做重试,主要是在服务端往客户端推送的时候,会加上重试的逻辑。

基于Http的意思是闲鱼的发送消息流程是通过Http请求进行的?但又说服务端能往客户端推送,所以闲鱼的消息系统是基于SSE这种单向通信的吗?
基于Http所以暂时不用做重试的意思是当HTTP请求成功就表示消息发送成功就不用重试了吗?

引用:当A发送的消息(黄色)首先到达服务端,因为前面没有其他version的消息,所以会将原数据返回给A,客户端A接收到消息的时候,再跟本地的消息做合并,只会保留一条消息。同时服务端也会将此消息发送给B,因为B本地也有一个version=1的消息,所以服务端过来的消息就会被过滤掉,这就出现消息丢失的问题。

为什么要将原数据返回给A?是拿原数据充当ACK包的作用吗?还是仅仅为了将服务端实际递增生成的version返回给客户端让客户端进行更新,保证消息时序性?
推拉隔离的设计,避免多次网络请求的问题。
没有明白是怎么避免多次网络请求的
引用:椎锋陷陈 发表于 2021-09-26 10:14
文章信息量较多,阅读后产生的疑问也比较多,望Jack Jiang大佬不吝赐教:

1)其实它还是有个双向互通的长连接,只是为了发送时省掉QoS送达保证机制,就用http了,因为http是请求响应机制,代码编写起来简单而且通用。其实你看文章内容就知道,闲鱼的这套im核心,还是比较凑活的,可能当初设计时也没有太重视,设计的人实时通信这方面的经验也不是特别足。

2)这个version看起来有点蛋疼,说的很绕,我也懒得仔细去理解了,反正不管怎么说,这肯定不是最佳实践。
引用:逍遥小子 发表于 2021-09-26 10:17
推拉隔离的设计,避免多次网络请求的问题。
没有明白是怎么避免多次网络请求的

文章中的意思,应该是通过缓存队列将消息进行了批量合并拉取,不用每次都一条条拉,是这个意思
引用:JackJiang 发表于 2021-09-26 12:14
1)其实它还是有个双向互通的长连接,只是为了发送时省掉QoS送达保证机制,就用http了,因为http是请求响 ...

谢谢JackJiang大佬解答,的确整篇文章看下来,就感觉很多地方的实现有点迷惑。。。
引用:椎锋陷陈 发表于 2021-09-26 14:14
谢谢JackJiang大佬解答,的确整篇文章看下来,就感觉很多地方的实现有点迷惑。。。

通常看起来很绕的算法或逻辑,要么就是非常精巧,要么就是非常笨拙,这个算法应该不是前者,所以没有必要太纠结
问题确实很多,大厂的IM系统能架构成这样,确实让人汗颜但是也有值得学习的地方,
签名:
引用:Feng_N7pwQ 发表于 2021-10-25 14:47
问题确实很多,大厂的IM系统能架构成这样,确实让人汗颜但是也有值得学习的地方,

应该当时只是临时应急搞的
从0~1确实不太好,但没做过也正常。
但是 讲的细节较多,挺好;
并且还讲了钉钉的
签名: im从业10年以上,欢迎切磋![url=http://www.52im.net/static/image/smiley/default/handshake.gif]http://www.52im.net/static/image/smiley/default/handshake
很佩服站长,几年如一日坚持
签名: im从业10年以上,欢迎切磋![url=http://www.52im.net/static/image/smiley/default/handshake.gif]http://www.52im.net/static/image/smiley/default/handshake
引用:Frank 发表于 2023-04-25 20:14
很佩服站长,几年如一日坚持

打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部