到达率99.9%:闲鱼消息在高速上换引擎(集大成)

简介: 记录这一年闲鱼消息的优化之路

 

1. 背景

在2020年年初的时候接手了闲鱼的消息,当时的消息存在各种问题,网上的舆情也是接连不断:“闲鱼消息经常丢失”、“消息用户头像乱了”、“订单状态不对”(相信现在看文章的你还在吐槽闲鱼的消息)。所以闲鱼的稳定性是一个亟待解决的问题,我们调研了集团的一些解决方案,例如钉钉的IMPass。直接迁移的成本和风险都是比较大,包括服务端数据需要双写、新老版本兼容等。

那基于闲鱼现有的消息架构和体系,如何来保证它的稳定性?治理应该从哪里开始?现在闲鱼的稳定性是什么样的?如何衡量稳定性?希望这篇文章,能让大家看到一个不一样的闲鱼消息。

2. 行业方案

消息的投递链路大致分为三步:发送者发送,服务端接收然后落库,服务端通知接收端。特别是移动端的网络环境比较复杂,可能你发着消息,网络突然断掉了;可能消息正在发送中,网络突然好了,需要重发。

 

在如此复杂的网络环境下,是如何稳定可靠的进行消息投递的?对发送者来说,它不知道消息是否有送达,要想做到确定送达,就需要加一个响应机制,类似下面的响应逻辑:

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

上面流程看似简单,关键是中间有个服务端转发过程,问题就在于谁来回这个确认信息,什么时候回这个确认信息。网上查到比较多的是如下一个必达模型,如下图所示:

 

 

[发送流程]

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

[接收流程]

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

一个可信的消息送达系统就是靠的6条报文来保证的,有这个投递模型来决定消息的必达,中间任何一个环节出错,都可以基于这个request-ack机制来判定是否出错并重试。看下在第4.2章中,也是参考了上面这个模型,客户端发送的逻辑是直接基于http的所以暂时不用做重试,主要是在服务端往客户端推送的时候,会加上重试的逻辑。

3. 闲鱼消息的问题

刚接手闲鱼消息,没有稳定相关的数据,所以第一步还是要对闲鱼消息做一个系统的排查,首先对消息做了全链路埋点。

 

基于消息的整个链路,我们梳理出来了几个关键的指标:发送成功率、消息到达率、客户端落库率。整个数据的统计都是基于埋点来做的。在埋点的过程总,发现了一个很大的问题:闲鱼的消息没有一个全局唯一的ID,导致在全链路埋点的过程中,无法唯一确定这条消息的生命周期。

3.1 消息唯一性问题

 


之前闲鱼的消息是通过3个变量来唯一确定一个消息

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

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

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

3.2 消息推送逻辑问题

之前闲鱼的消息的推送逻辑也存在很大的问题,发送端使用http请求,发送消息内容,基本不会出问题,问题是出现在服务端给另外一端推送的时候。如下图所示,

 

服务端在给客户端推送的时候,会先判断此时客户端是否在线,如果在线才会推送,如果不在线就会推离线消息。这个做法就非常的简单粗暴。长连接的状态如果不稳定,导致客户端真实状态和服务端的存储状态不一致,就导致消息不会推送到端上。

3.3 客户端逻辑问题

除了以上跟服务端有关系外,还有一类问题是客户端本身设计的问题,可以归结为以下几种情况:

  • 多线程问题

反馈消息列表页面会出现布局错乱,本地数据还没有完全初始化好,就开始渲染界面

  • 未读数和小红点的计数不准确

本地的显示数据和数据库存储的不一致。

  • 消息合并问题

本地在合并消息的时候,是分段合并的,不能保证消息的连续性和唯一性。

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

 

4. 我们的解法 - 引擎升级

进行治理的第一步就是,解决闲鱼消息的唯一性的问题。我们也调研了钉钉的方案,钉钉是服务端全局维护消息的唯一ID,考虑到闲鱼消息的历史包袱,我们这边采用UUID作为消息的唯一ID,这样就可以在消息链路埋点以及去重上得到很大的改善。

4.1 消息唯一性

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

 

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

- (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;}];...
}

4.2 重发重连

 


基于#2中的重发重连模型,闲鱼完善了服务端的重发的逻辑,客户端完善了重连的逻辑。

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

已经有小伙伴发表了一篇文章:《向消息延迟说bybye:闲鱼消息及时到达方案(详细)》,讲解了下关于网络不稳定给闲鱼消息带来的问题,在这里就不多赘述了。

4.3 数据同步

重发重连是解决的基础网络层的问题,接下来就要看下业务层的问题,很多复杂情况是通过在业务层增加兼容代码来解决的,闲鱼消息的数据同步就是一个很典型的场景。在完善数据同步的逻辑之前,我们也调研过钉钉的一整套数据同步方案,他们主要是由服务端来保证的,背后有一个稳定的长连接保证,大致流程如下:

 

闲鱼的服务端暂时还没有这种能力,原因详见4.5的服务端存储模型。所以闲鱼这边只能从客户端来控制数据同步的逻辑,数据同步的方式包括:拉取会话、拉取消息、推送消息等。因为涉及到的场景比较复杂,之前有个场景就是推送会触发增量同步,如果推送过多的话,会同时触发多次网络请求,为了解决这个问题,我们也做了相关的推拉队列隔离。

 

客户端控制的策略就是如果在拉取的话,会先将push过来的消息加到缓存队列里面,等拉取的结果回来,会再跟本地缓存的逻辑做合并,这样就可以避免多次网络请求的问题。之前同事已经写了一篇关于推拉流控制的逻辑,《如何有效缩短闲鱼消息处理时长》,这里也不过多赘述了。

4.4 客户端模型

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

 

在客户端会构建上图一样的树,这棵树主要保存的是会话显示的相关信息,比如未读数、红点以及最新消息摘要,子节点更新,会顺带更新到父节点,构建树的过程也是已读和未读数更新的过程。其中比较复杂的场景是闲鱼情报社,这个其实是一个文件夹节点,它包含了很多个子的会话,这就决定了他的消息排序、红点计数以及消息摘要的更新逻辑会更复杂,服务端告知客户端子会话的列表,然后客户端再去拼接这些数据模型。

4.5 服务端存储模型

 

在4.3中大概讲了客户端的请求逻辑,历史消息会分为增量和全量域同步。这个域其实是服务端的一层概念,本质上就是用户消息的一层缓存,消息过来之后会暂存在缓存中,加速消息读取。但是这个设计也存在一个缺陷,就是域环是有长度的,最多保存256条,当用户的消息数多于256条,只能从数据库中读取。

关于服务端的存储方式,我们也调研过钉钉的方案,是写扩散,优点就是可以很好地对每位用户的消息做定制化,比如钉的逻辑,缺点就是存储量很很大。闲鱼的这套解决方案,应该是介于读扩散和写扩散之间的一种解决方案。这个设计方式不仅使客户端逻辑复杂,服务端的数据读取速度也会比较慢,后续这块也可以做优化。

5. 我们的解法 - 质量监控

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

5.1 全链路排查

 

全链路排查是基于用户的实时行为日志,客户端的埋点通过集团实时处理引擎Flink,将数据清洗到SLS里面,用户的行为包括了消息引擎对消息的处理、用户的点击/访问页面的行为、以及用户的网络请求。服务端测会有一些长连接推送以及重试的日志,也会清洗到SLS,这样就组成了从服务端到客户端全链路的排查的方案,详情请参考《消息质量平台系列文章|全链路排查篇》。

5.2 对账系统

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

 

在用户离开会话的时候,我们会统计当前会话一定数量的消息,生成一个md5的校验码,上报到服务端。服务端拿到这个校验码之后再判定是否消息是正确的,经过抽样数据验证,消息的准确性基本都在99.99%。

6 核心数据指标

我们在统计消息的关键指标的时候,遇到点问题,之前我们是用用户埋点来统计的,发现会有3%~5%的数据差;所以后来我们采用抽样实时上报的数据来计算数据指标。

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

客户端实际收到的消息的定义为消息落库才算是
该指标不区分离线在线,取用户当日最后一次更新设备时间,理论上当天且在此时间之前下发的消息都应该收到。

 


最新版本的到达率已经基本达到99.9%,从舆情上来看,反馈丢消息的也确实少了很多。

7. 未来规划

整体看来,经过一年的治理,闲鱼的消息在慢慢的变好,但还是存在一些待优化的方面:

  • 现在消息的安全性不足,容易被黑产利用,借助消息发送一些违规的内容。
  • 消息的扩展性较弱,增加一些卡片或者能力就要发版,缺少了动态化和扩展的能力。
  • 现在底层协议比较难扩展,后续还是要规范一下协议。
  • 从业务角度看,消息应该是一个横向支撑的工具性或者平台型的产品,规划可以快速对接二方和三方的快速对接。

在2021年,我们会持续关注消息相关的用户舆情,希望闲鱼消息能帮助闲鱼用户更好的完成二手交易。

作者:闲鱼技术——景松

本文为阿里云原创内容,未经允许不得转载

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/514264.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

1小时打造HaaS版小小蛮驴智能车

1、认识一下小小蛮驴真面目 1.1、组件部分 HaaS100核心板 HaaS100是一款物联网场景中的标准硬件&#xff0c;并配套嵌入到硬件中的软件驱动及功能模块&#xff0c;为用户提供物联网设备高效开发服务。 HaaS100核心板有着丰富的外设接口&#xff0c;如下所示&#xff1a; 智…

Spring Boot Admin 集成诊断利器 Arthas 实践

简介&#xff1a; Arthas 是 Alibaba 开源的 Java 诊断工具&#xff0c;具有实时查看系统的运行状况&#xff1b;查看函数调用参数、返回值和异常&#xff1b;在线热更新代码&#xff1b;秒解决类冲突问题&#xff1b;定位类加载路径&#xff1b;生成热点&#xff1b;通过网页诊…

设计方案,拿来吧你!

作者&#xff1a;零一来源&#xff1a;前端印象前言大家好&#xff0c;我是零一&#xff0c;今天要跟大家聊聊开发流程中不起眼的环节——设计方案。你们可能没听过&#xff0c;也可能只是简单得走过过场&#xff0c;别划走&#xff0c;这非常重要&#xff01;在字节&#xff0…

借力阿里云存储产品 延锋彼欧加速数字化重塑

简介&#xff1a; 延锋彼欧作为汽车外饰件生产的领航企业&#xff0c;通过基于业务和数据驱动的数字化管理&#xff0c;释放工业设备数据潜能提升产能。依托阿里云“稳定、安全、可靠、易用”的存储服务&#xff0c;延锋彼欧的发展步伐将更为稳健。 “一日骋千里&#xff0c;无…

英雄帖!移动云首批最有价值专家(MVP)招募开始了!

这是开发者的时代&#xff0c;这是价值重塑的时代。站在科技的潮头&#xff0c;我们期待去引领、去挖掘、去创造……移动云已迎来飞速发展的黄金期&#xff0c;移动云开发者社区将成为业界优秀开发者的聚集地。今天&#xff0c;移动云开发者社区正式开启移动云MVP首批招募&…

无责任畅想:云原生中间件的下一站

简介&#xff1a; 本文源自 2020 年 12 月 20 日作者在云原生社区 meetup 第二期北京站演讲 《Apache Dubbo-go 在云原生时代的实践与探索》的部分内容 自从以 2013 年开源的 docker 为代表的的容器技术和以 2014 年开源的 K8s 为代表的容器编排技术登上舞台之后&#xff0c;相…

深度剖析:Redis 分布式锁到底安全吗?看完这篇文章彻底懂了!

作者 | Kaito 来源 | 水滴与银弹阅读本文大约需要 20 分钟。大家好&#xff0c;我是 Kaito。这篇文章我想和你聊一聊&#xff0c;关于 Redis 分布式锁的「安全性」问题。Redis 分布式锁的话题&#xff0c;很多文章已经写烂了&#xff0c;我为什么还要写这篇文章呢&#xff1f;因…

Spring Boot 微服务性能下降九成!使用 Arthas 定位根因

简介&#xff1a; 接收到公司业务部门的开发反馈&#xff0c;应用在升级公司内部框架后&#xff0c;UAT&#xff08;预生产&#xff09;环境接口性能压测不达标。 背景 接收到公司业务部门的开发反馈&#xff0c;应用在升级公司内部框架后&#xff0c;UAT&#xff08;预生产&a…

阿里研究员:线下环境为何不稳定?怎么破

简介&#xff1a; 为什么线下环境的不稳定是必然的&#xff1f;我们怎么办&#xff1f;怎么让它尽量稳定一点&#xff1f; 这篇文章想讲两件事&#xff1a; 为什么线下环境[1]的不稳定是必然的&#xff1f;我们怎么办&#xff1f;怎么让它尽量稳定一点&#xff1f; 此外&#…

谁说技术男不浪漫!90后程序员2天做出猫咪情绪识别软件

整理 | 王晓曼出品 | CSDN&#xff08;ID&#xff1a;CSDNnews&#xff09;9月1日&#xff0c;一则关于#程序员2天做出猫咪情绪识别软件#的话题登上微博热搜&#xff0c;参与阅读的人数达到了8218.1万&#xff0c;讨论次数1.3万&#xff0c;引发网友们的热议。高手在民间&#…

闲鱼如何一招保证推荐流稳如泰山

简介&#xff1a; 风雨不动安如山 背景 近几年互联网的快速发展中&#xff0c;互联网业务发展越来越复杂&#xff0c;业务也被拆分得越来越细&#xff0c;阿里内部业务也发生着翻天覆地的变化&#xff0c;从最初的单体应用&#xff0c;到后面的分布式集群&#xff0c;再到最近…

电商直播平台如何借助容器与中间件实现研发效率提升100%?

简介&#xff1a; 经过实际场景验证及用户的综合评估&#xff0c;电商直播平台借助全面的云原生容器化能力和中间件产品能力&#xff0c;大幅提升开发部署运维效率达50%~100%&#xff0c;极大地提升了用户体验&#xff0c;为业务持续发展打下了坚实的基础。 前言 直播带货是近…

在游戏运营行业,Serverless 如何解决数据采集分析痛点?

简介&#xff1a; 众所周知&#xff0c;游戏行业在当今的互联网行业中算是一棵常青树。在疫情之前的 2019 年&#xff0c;中国游戏市场营收规模约 2884.8 亿元&#xff0c;同比增长 17.1%。2020 年因为疫情&#xff0c;游戏行业更是突飞猛进。玩游戏本就是中国网民最普遍的娱乐…

字节大战腾讯元宇宙;Docker 自己定制镜像;VMware 云桌面助力秦皇岛市第一医院;微软开源 Cloud Katana;...

NEWS本周新闻回顾字节大战腾讯元宇宙&#xff1a;布局社交产品Pixsoul&#xff0c;上线游戏“重启世界”字节投资的代码乾坤&#xff0c;已于近日正式上线了元宇宙游戏《重启世界》。就在两个月前&#xff0c;被称为“元宇宙第一股”的Roblox登陆国内&#xff0c;由腾讯改名为《…

从 RxJS 到 Flink:如何处理数据流?

简介&#xff1a; 前端开发的本质是什么&#xff1f;响应式编程相对于 MVVM 或者 Redux 有什么优点&#xff1f;响应式编程的思想是否可以应用到后端开发中&#xff1f;本文以一个新闻网站为例&#xff0c;阐述在前端开发中如何使用响应式编程思想&#xff1b;再以计算电商平台…

Spring RSocket:基于服务注册发现的 RSocket 负载均衡

简介&#xff1a; RSocket 作为通讯协议的后起之秀&#xff0c;核心是二进制异步化消息通讯&#xff0c;是否也能和 Spring Cloud 技术栈结合&#xff0c;实现服务注册发现、客户端负载均衡&#xff0c;从而更高效地实现面向服务的架构&#xff1f;这篇文章我们就讨论一下 Spri…

双非院校计算机系毕业的学生能进大厂吗?

谈到大厂&#xff0c;我们常常会主动匹配与之对应的高学历。其实不论是大厂还是小公司&#xff0c;都是会筛简历的&#xff0c;这个毋庸置疑。从大厂招聘的结果上看&#xff0c;高学历人才的数量占据大头&#xff0c;而那些成功进入BAT、网易等大厂的专科生、二本三本学生&…

Python - 深夜数据结构与算法之 Heap Binary Heap

目录 一.引言 二.堆与二叉堆介绍 1.Heap 堆 2.Binary Heap 二叉堆 3.HeapifyUp 添加节点 4.HeapifyDown 删除节点 5.Heap 时间复杂度 6.Insert & Delete 代码实现 三.经典算法实战 1.Smallest-K [M14] 2.Sliding-Window-Max [239] 3.Ugly-Number [264] 4.Top-…

如何 0 改造,让单体/微服务应用成为 Serverless Application

简介&#xff1a; 随着 2013 年以 Docker 为代表的容器技术、CNCF 基金会以及 K8s 的发展等&#xff0c;云原生开始被广大开发者所熟知。云原生时代之前还有两个阶段&#xff1a;一是自建 IDC 机房&#xff0c;二是简单地把原有的应用搬迁到云上。自建 IDC 机房很难获得高可用、…

一文了解阿里一站式图计算平台GraphScope

简介&#xff1a; 随着大数据的爆发&#xff0c;图数据的应用规模不断增长&#xff0c;现有的图计算系统仍然存在一定的局限。阿里巴巴拥有全球最大的商品知识图谱&#xff0c;在丰富的图场景和真实应用的驱动下&#xff0c;阿里巴巴达摩院智能计算实验室研发并开源了全球首个一…