Jack Jiang

我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
posts - 256, comments - 13, trackbacks - 0, articles - 0

置顶随笔

     摘要: 本文的上篇我们讨论了在线实时消息的投递,如果接收方用户B不在线,系统是如何保证离线消息的可达性的呢?这就是本文要讨论的问题。  阅读全文

posted @ 2016-11-18 14:39 Jack Jiang 阅读(2906) | 评论 (0)编辑 收藏

     摘要: 虽然C10K问题已被妥善解决,但对于即时通讯应用(或其它网络编程方面)的开发者而言,研究C10K问题仍然价值巨大,因为技术的发展都是有规律和线索可循的,了解C10K问题及其解决思路,通过举一反三,或许可以为你以后面对类似问题提供更多可借鉴的思想和解决问题的实践思路。而这,也正是撰写本文的目的所在。  阅读全文

posted @ 2016-10-21 16:02 Jack Jiang 阅读(2537) | 评论 (0)编辑 收藏

     摘要: 本文将以新手的视角引导你阅读相关文章,以便为从零开发一个移动端IM做好方方面面的知识准备:包括但不限于网络编程基础、通信协议的选型、IM的架构设计等等。  阅读全文

posted @ 2016-08-29 17:42 Jack Jiang 阅读(3054) | 评论 (0)编辑 收藏

     摘要: 本文将简要介绍TeamTalk开源的过去和现在,为打算研究和采用TeamTalk的同行提供一定程度的参考。  阅读全文

posted @ 2016-08-09 17:25 Jack Jiang 阅读(2661) | 评论 (0)编辑 收藏

     摘要: 本文基于作者的实践以及相关资料的整理,总结了自已对Android进程和Service保活的理解,希望能为你的应用开发带来启发。  阅读全文

posted @ 2016-08-02 22:43 Jack Jiang 阅读(2421) | 评论 (0)编辑 收藏

     摘要: 本文将介绍如何在现有的技术基础上选择合适的方案开发一个“服务器推”(Comet技术)的应用,最优的方案还是取决于应用需求的本身。相对于传统的 Web 应用, 开发 Comet 应用具有一定的挑战性。  阅读全文

posted @ 2016-07-28 11:07 Jack Jiang 阅读(1405) | 评论 (0)编辑 收藏

     摘要: 本文对服务器推送技术(SSE)进行了详细的介绍,包含浏览器端和服务器端的相应实现细节,为在实践中使用该技术提供了指南  阅读全文

posted @ 2016-07-22 18:03 Jack Jiang 阅读(1072) | 评论 (0)编辑 收藏

     摘要: Web端即时通讯技术因受限于浏览器的设计限制,一直以来实现起来并不容易,主流的Web端即时通讯方案大致有4种:传统Ajax短轮询、Comet技术、WebSocket技术、SSE(Server-sent Events)。本文将简要介绍这4种技术的原理,并指出各自的异同点、优缺点等。  阅读全文

posted @ 2016-07-15 15:08 Jack Jiang 阅读(1674) | 评论 (2)编辑 收藏

     摘要: Web端的IM应用,由于浏览器的兼容性以及其固有的“客户端请求服务器处理并响应”的通信模型,造成了要在浏览器中实现一个兼容性较好的IM应用,其通信过程必然是诸多技术的组合,本文的目的就是要详细探讨这些技术并分析其原理和过程。   阅读全文

posted @ 2016-07-12 15:59 Jack Jiang 阅读(5348) | 评论 (0)编辑 收藏

     摘要: 文演示的是一个Android客户端程序,通过UDP协议与两个典型的NIO框架服务端(分别用MINA2和Netty4来实现),实现跨平台双向通信的完整Demo。  阅读全文

posted @ 2016-06-30 16:57 Jack Jiang 阅读(649) | 评论 (0)编辑 收藏

     摘要: 本文将演示一个iOS客户端程序,通过UDP协议与两个典型的NIO框架服务端(将分别用MINA2和Netty4来实现),实现跨平台双向通信的完整Demo。  阅读全文

posted @ 2016-06-28 22:11 Jack Jiang 阅读(1266) | 评论 (0)编辑 收藏

     摘要: 本文是《NIO框架入门》系列文章中的第2篇,将演示的是一个基于MINA2的UDP服务端和一个标准UDP客户端(Java实现)双向通信的完整例子。  阅读全文

posted @ 2016-06-24 14:38 Jack Jiang 阅读(708) | 评论 (0)编辑 收藏

     摘要: 本文将演示的是一个基于Netty4的UDP服务端和一个标准UDP客户端(Java实现)双向通信的完整例子。实际上,Netty4的UDP例子非常难找,官方的代码演示里只有一个简单的UDP广播例子,不足以用于演示Netty4的UDP通信最佳实践。  阅读全文

posted @ 2016-06-20 14:48 Jack Jiang 阅读(1317) | 评论 (0)编辑 收藏

     摘要: MobileIMSDK是一套专为移动端开发的原创即时通讯框架:超轻量级、高度提炼,lib包50KB以内;完全基于UDP协议实现;客户端支持iOS、Android、标准Java平台;可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。  阅读全文

posted @ 2015-12-14 15:18 Jack Jiang 阅读(2677) | 评论 (0)编辑 收藏

     摘要: MobileIMSDK是专为移动端开发的原创即时通讯开源框架:超轻量级、高度提炼,lib包50KB以内;完全基于UDP协议实现;客户端支持iOS、Android、标准Java平台;可应用于跨设备、跨网络的聊天APP、企业OA、消息推送等各种场景。  阅读全文

posted @ 2015-12-01 16:06 Jack Jiang 阅读(3196) | 评论 (2)编辑 收藏

2021年11月27日

     摘要: 本文由公众号“后台技术汇”分享,原题“基于实践,设计一个百万级别的高可用 & 高可靠的 IM 消息系统”,原文链接在文末。由于原文存在较多错误和不准确内容,有大量修订和改动。1、引言大家好,我是公众号“后台技术汇”的博主“一枚少年”。本人从事后台开发工作 3 年有余了,其中让我感触最深刻的一个项...  阅读全文

posted @ 2021-11-27 13:00 Jack Jiang 阅读(25) | 评论 (0)编辑 收藏

2021年11月17日

本文由阿里闲鱼技术团队逸昂分享,原题“消息链路优化之弱感知链路优化”,有修订和改动,感谢作者的分享。

1、引言

闲鱼的IM消息系统作为买家与卖家的沟通工具,增进理解、促进信任,对闲鱼的商品成交有重要的价值,是提升用户体验最关键的环节。

然而,随着业务体量的快速增长,当前这套消息系统正面临着诸多急待解决的问题。

以下几个问题典型最为典型:

  • 1)在线消息的体验提升;
  • 2)离线推送的到达率;
  • 3)消息玩法与消息底层系统的耦合过强。

经过评估,我们认为现阶段离线推送的到达率问题最为关键,对用户体验影响较大。

本文将要分享的是闲鱼IM消息在解决离线推送的到达率方面的技术实践,内容包括问题分析和技术优化思路等,希望能带给你启发。

学习交流:

- 即时通讯/推送技术开发交流5群:215477170 [推荐]

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

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

本文已同步发布于:http://www.52im.net/thread-3748-1-1.html )

2、系列文章

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

3、通信链路类型的划分

从数据通信链接的技术角度,我们根据闲鱼客户端是否在线,将整体消息链路大致分为强感知链路和弱感知链路。

强感知链路由以下子系统或模块:

  • 1)发送方客户端;
  • 2)idleapi-message(闲鱼的消息网关);
  • 3)heracles(闲鱼的消息底层服务);
  • 4)accs(阿里自研的长连接通道);
  • 5)接收方客户端组成。

整条链路的核心指标在于端到端延迟和消息到达率。

强感知链路中的双方都是在线的,消息到达客户端就可以保证接收方感知到。强感知链路的主要痛点在消息的端到端延迟。

弱感知链路与强感知链路的主要不同在于:弱感知链路的接收方是离线的,需要依赖离线推送这样的方式送达。

因此弱感知链路的用户感知度不强,其核心指标在于消息的到达率,而非延迟。

所以当前阶段,优化弱感知链路的重点也就是提升离线消息的到达率。换句话说,提升离线消息到达率问题,也就是优化弱感知链路本身。

4、消息系统架构概览

下图一张整个IM消息系统的架构图,感受下整体链路:

如上图所示,各主要组件和子系统分工如下:

  • 1)HSF是一个远程服务框架,是dubbo的内部版本;
  • 2)tair是阿里自研的分布式缓存框架,支持 memcached、Redis、LevelDB 等不同存储引擎;
  • 3)agoo是阿里的离线推送中台,负责整合不同厂商的离线推送通道,向集团用户提供一个统一的离线推送服务;
  • 4)accs是阿里自研的长连接通道,为客户端、服务端的实时双向交互提供便利;
  • 5)lindorm是阿里自研的NoSQL产品,与HBase有异曲同工之妙;
  • 6)域环是闲鱼消息优化性能的核心结构,用来存储用户最新的若干条消息。

强感知链路和弱感知链路在通道选择上是不同的:

  • 1)强感知链路使用accs这个在线通道;
  • 2)弱感知链路使用agoo这个离线通道。

5、弱感知链路到底怎么定义

通俗了说,弱感知链路指的就是离线消息推送系统。

相比较于在线消息和端内推送(也就是上面说的强感知链路),离线推送难以确保被用户感知到。

典型的情况包括:

  • 1)未发送到用户设备:即推送未送达用户设备,这种情况可以从通道的返回分析;
  • 2)发送到用户设备但没有展示到系统通知栏:闲鱼曾遇到通道返回成功,但是用户未看到推送的案例;
  • 3)展示到通知栏,并被系统折叠:不同安卓厂商对推送的折叠策略不同,被折叠后,需用户主动展开才能看到内容,触达效果明显变差;
  • 4)展示到通知栏,并被用户忽略:离线推送的点击率相比于在线推送更低。

针对“1)未发送到用户设备”,原因有:

  • 1)离线通道的token失效;
  • 2)参数错误;
  • 3)用户关闭应用通知;
  • 4)用户已卸载等。

针对“3)展示到通知栏,并被系统折叠”,原因有:

  • 1)通知的点击率;
  • 2)应用在厂商处的权重;
  • 3)推送的数量等。

针对“4)展示到通知栏,并被用户忽略”,原因有:

  • 1)用户不愿意查看推送;
  • 2)用户看到了推送,但是对内容不感兴趣;
  • 3)用户在忙别的事,无暇处理。

总之:以上这些离线消息推送场景,对于用户来说感知度不高,我们也便称之为弱感知链路。

6、弱感知链路的逻辑构成

我们的弱感知链路分为3部分,即:

  • 1)系统;
  • 2)通道;
  • 3)用户。

共包含了Hermes、agoo、厂商、设备、用户、承接页这几个环节。具体如下图所示。

从推送的产生到用户最终进入APP,共分为如下几个步骤:

  • 步骤1:Hermes是闲鱼的用户触达系统,负责人群管理、内容管理、时机把控,是整个弱感知链路的起点。;
  • 步骤2:agoo是阿里内部承接离线推送的中台,是闲鱼离线推送能力的基础;
  • 步骤3:agoo实现离线推送依靠的是厂商的推送通道(如:苹果的apns通道、Google的fcm通道、及国内各厂商的自建通道。;
  • 步骤4:通过厂商的通道,推送最终出现在用户的设备上,这是用户能感知到推送的前提条件;
  • 步骤5:如果用户刚巧看到这条推送,推送的内容也很有趣,在用户的主动点击下会唤起APP,打开承接页,进而给用户展示个性化的商品。

经过以上5个步骤,至此弱感知链路就完成了使命。

7、弱感知链路面临的具体问题

弱感知链路的核心问题在于:

  • 1)推送的消息是否投递给了用户;
  • 2)已投递到的消息用户是否有感知。

这对应推送的两个阶段:

  • 1)推送消息是否已到达设备;
  • 2)用户是否查看推送并点击。

其中:到达设备这个阶段是最基础的,也是本次优化的核心。

我们可以将每一步的消息处理量依次平铺,展开为一张漏斗图,从而直观的查看链路的瓶颈。

漏斗图斜率最大的地方是优化的重点,差异小的地方不需要优化:

通过分析以上漏斗图,弱感知链路的优化重点在三个方面:

  • 1)agoo受理率:是指我们发送推送请到的数量到可以通过agoo(阿里承接离线推送的中台)转发到厂商通道的数量之间的漏斗;
  • 2)厂商受理率:是指agoo中台受理的量到厂商返回成功的量之间的漏斗;
  • 3)Push点击率:也就通过以上通道最终已送到到用户终端的消息,是否最终转化为用户的主动“点击”。

有了优化方向,我们来看看优化手段吧。

8、我们的技术优化手段

跟随推送的视角,顺着链路看一下我们是如何进行优化的。

8.1 agoo受理率优化

用户的推送,从 Hermes 站点搭乘“班车”,驶向下一站: agoo。

这是推送经历的第一站。到站一看,傻眼了,只有不到一半的推送到站下车了。这是咋回事嘞?

这就要先说说 agoo 了,调用 agoo 有两种方式:

  • 1)指定设备和客户端,agoo直接将推送投递到相应的设备;
  • 2)指定用户和客户端,agoo根据内部的转换表,找到用户对应的设备,再进行投递。

我们的系统不保存用户的设备信息。因此,是按照用户来调用agoo的。

同时:由于没有用户的设备信息,并不知道用户是 iOS 客户端还是 Android 客户端。工程侧不得不向 iOS 和 Android 都发送一遍推送。虽然保证了到达,但是,一半的调用都是无效的。

为了解这个问题:我们使用了agoo的设备信息。将用户转换设备这一阶段提前到了调用 agoo 之前,先明确用户对应的设备,再指定设备调用 agoo,从而避免无效调用。

agoo调用方式优化后,立刻剔除了无效调用,agoo受理率有了明显提升。

至此:我们总算能对 agoo 受理失败的真正原因做一个高大上的分析了。

根据统计:推送被 agoo 拒绝的主要原因是——用户关闭了通知权限。同时,我们对 agoo 调用数据的进一步分析发现——有部分用户找不到对应的设备。 优化到此,我们猛然发现多了两个问题。

那就继续优化呗:

  • 1)通知体验优化,引导打开通知权限;
  • 2)与agoo共建设备库,解决设备转换失败的问题。

这两个优化方向又是一片新天地,我们择日再聊。

8.2 厂商推送通道受理率优化

推送到达 agoo ,分机型搭乘厂商“专列”,驶向下一站:用户设备。

这是推送经历的第二站。出站查票,发现竟然超员了。

于是乎:我们每天有大量推送因为超过厂商设定的限额被拦截。

为什么会这样呢?

实际上:提供推送通道的厂商(没错,各手机厂商的自家推送通道良莠不齐),为了保证用户体验,会对每个应用能够推送的消息总量进行限制。

对于厂商而言,这个限制会根据推送的类型和应用的用户规模设定——推送主要分为产品类的推送和营销类的推送。

厂商推送通道对于不同类型消息的限制是:

  • 1)对于产品类推送,厂商会保证到达;
  • 2)对于营销类推送,厂商会进行额度限制;
  • 3)未标记的推送,默认作为营销类推送对待。

我们刚好没有对推送进行标记,因此触发了厂商的推送限制。

这对我们的用户来说,会带来困扰。闲鱼的交易,很依赖买卖家之间的消息互动。这部分消息是需要确保到达的。

同样:订单类的消息、用户的关注,也需要保证推送给用户。

根据主流厂商的接口协议,我们将推送的消息分为以下几类,并进行相应标记:

  • 1)即时通讯消息;
  • 2)订单状态变化;
  • 3)用户关注内容;
  • 4)营销消息这几类。

同时,在业务上,我们也进行了推送的治理——将用户关注度不高的消息,取消推送,避免打扰。

经过这些优化,因为超过厂商限额而被拦截的推送实现了清零。

8.3 Push点击率优化

通过优化agoo受理率、厂商受理率,我们解决了推送到达量的瓶颈。但即使消息被最终送达,用户到底点击了没有?这才是消息推送的根本意义所在。

于是,在日常的开发测试过程中,我们发现了推送的两个体验问题:

  • 1)用户点击Push有开屏广告;
  • 2)营销Push也有权限校验,更换用户登陆后无法点击。

对于开屏广告功能,我们增加了Push点击跳过广告的能力。

针对Push的权限校验功能,闲鱼根据场景做了细分:

  • 1)涉及个人隐私的推送,保持权限校验不变;
  • 2)营销类的推送,放开权限校验。

以上是点击体验的优化,我们还需要考虑用户的点击意愿。

用户点击量与推送的曝光量、推送素材的有趣程度相关。推送的曝光量又和推送的到达量、推送的到达时机有关。

具体的优化手段是:

  • 1)在推送内容上:我们需要优化的是推送的时机和相应的素材;
  • 2)在推送时机上:算法会根据用户的偏好和个性化行为数据,计算每个用户的个性化推送时间,在用户空闲的时间推送(避免在不合适的时间打扰用户,同时也能提升用户看到推送的可能性)。
  • 3)在推送素材上:算法会根据素材的实时点击反馈,对素材做实时赛马。只发用户感兴趣的素材,提高用户点击意愿。

9、实际优化效果

通过以上我们的分析和技术优化手段,整体弱推送链路链路有了不错的提升,离线消息的到达率相对提升了两位数。

10、写在最后

本篇主要和大家聊的是只是IM消息系统链路中的一环——弱感知链路的优化,落地到到具体的业务也就是离线消息送达率问题。

整体IM消息系统,还是一个比较复杂的领域。

我们在消息系统的发展过程中,面临着如下问题:

  • 1)如何进行消息的链路追踪;
  • 2)如何保证IM消息的快速到达(见《闲鱼亿级IM消息系统的及时性优化实践》);
  • 3)如何将消息的玩法和底层能力分离;
  • 4)离线推送中如何通过用户找到对应的设备。

这些问题,我们在以前的文章中有所分享,以后也会陆续分享更多,敬请期待。

附录:相关资料

[1] Android P正式版即将到来:后台应用保活、消息推送的真正噩梦

[2] 一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践

[3] 一套亿级用户的IM架构技术干货(上篇):整体架构、服务拆分等

[4] 一套亿级用户的IM架构技术干货(下篇):可靠性、有序性、弱网优化等

[5] 从新手到专家:如何设计一套亿级消息量的分布式IM系统

[6] 企业微信的IM架构设计揭秘:消息模型、万人群、已读回执、消息撤回等

[7] 融云技术分享:全面揭秘亿级IM消息的可靠投递机制

[8] 移动端IM中大规模群消息的推送如何保证效率、实时性?

[9] 现代IM系统中聊天消息的同步和存储方案探讨

[10] 新手入门一篇就够:从零开发移动端IM

[11] 移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”

[12] 移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

[13] IM消息送达保证机制实现(一):保证在线实时消息的可靠投递

[14] IM消息送达保证机制实现(二):保证离线消息的可靠投递

[15] 零基础IM开发入门(一):什么是IM系统?

[16] 零基础IM开发入门(二):什么是IM系统的实时性?

[17] 零基础IM开发入门(三):什么是IM系统的可靠性?

[18] 零基础IM开发入门(四):什么是IM系统的消息时序一致性?

本文已同步发布于“即时通讯技术圈”公众号。

同步发布链接是:http://www.52im.net/thread-3748-1-1.html 

posted @ 2021-11-17 12:24 Jack Jiang 阅读(52) | 评论 (0)编辑 收藏

2021年11月10日

     摘要: 本文由公众号“水滴与银弹”号主Kaito原创分享,原题“搞懂异地多活,看这篇就够了”,为使文章更好理解,即时通讯网收录时有修订。1、引言前几天技术群里有群友问我52im社区里有没有IM分布式系统异地多活方面的文章,我仔细想了想,除了微信分享的几篇文章里有提到容灾和异地多活(只是大致提过,没有详细展开),确实目前还没有系统性的异地多活技术资料可供参考。...  阅读全文

posted @ 2021-11-10 15:18 Jack Jiang 阅读(49) | 评论 (0)编辑 收藏

2021年11月1日

     摘要: 本文引用了ELab团队、腾讯大讲堂两个公众号分享的文章内容,引用内容见文末参考资料,感谢原作者的无私分享。1、引言对于市面上主流的IM来说,跟二维码有关的功能,比如扫码加好友、扫码登陆、扫码加群等,都是很常见的。这是微信的扫码登录功能:这是微信的扫码加好友功能: 二维码技术使用起来很简单,本系列的前三篇文章也专门针对IM扫码登录这个功能做了详细的分享,但本着学习技术不留死角的习惯,我认为...  阅读全文

posted @ 2021-11-01 19:49 Jack Jiang 阅读(66) | 评论 (0)编辑 收藏

2021年10月26日

     摘要: 本文由融云技术团队原创分享,原题“万字干货:IM “消息”列表卡顿优化实践”,为使文章更好理解,内容有修订。1、引言随着移动互联网的普及,无论是IM开发者还是普通用户,IM即时通讯应用在日常使用中都是必不可少的,比如:熟人社交的某信、IM活化石的某Q、企业场景的某钉等,几乎是人人必装。以下就是几款主流的IM应用(看首页就知道是哪款,我就不废话了):正...  阅读全文

posted @ 2021-10-26 14:41 Jack Jiang 阅读(77) | 评论 (0)编辑 收藏

2021年10月19日

本文由阿里闲鱼技术团队有攸分享,原题“向消息延迟说bybye:闲鱼消息及时到达方案”,有修订和改动,感谢作者的分享。

1、引言

IM消息作为闲鱼用户重要的交易咨询工具,核心目标有两点:

  • 1)第一是保证用户的消息不丢失;
  • 2)第二是保证用户的消息及时送达接收方。

IM消息根据消息的接收方设备是否在线,分为离线和在线推送。数据显示目前闲鱼每天有超过一半以上的IM消息是走在线通道的,而在线消息的到达率、及时性是直接影响用户体验的。

本文将根据闲鱼IM消息系统在消息及时性方面的优化实践,详细分析了IM在线通道面临的各种技术问题,并通过相应的技术手段来优化从而保证用户消息的及时到达。

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

学习交流:

- 即时通讯/推送技术开发交流5群:215477170 [推荐]

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

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

本文同步发布于:http://www.52im.net/thread-3726-1-1.html

2、系列文章

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

3、当前面临的问题

3.1 端内长连接中断

在IM场景中,用户与云端通信频繁,且为了实现用户的消息及时到达,往往采用云端下推消息的方式触达用户,所以用户在线时设备与云端会维持一条TCP长连接通道,可以更轻量级的与服务端进行交互,现代IM即时通讯的下行消息都是通过长连下发的。

当前闲鱼IM消息系统使用的是ACCS长连接,ACCS是淘宝无线提供的全双工、低延时、高安全的通道服务。

但由于用户设备网络状态的不确定性,可能会发生各种各样的网络异常情况导致ACCS长连接通道中断。而长连接一旦意外中断,就会导致用户无法及时收到在线消息。

针对这个问题,我们需要尽可能及时的感知到长连中断并尝试重连。具体的优化思路会在本文后面的内容中分享。

3.2 下推的消息未达

感知长连中断并重连只能在大多数时间保证长连接的有效性,但是在长连接无效或不稳定期间下推的消息客户端可能根本收不到。

简单说就是仅仅有重连机制无法保证下行消息必达,可能有以下场景导致下行消息失败:

  • 1)服务端发送下行消息时长连畅通,消息在传输路上通道断掉,客户端无法收到;
  • 2)设备的在线状态存在延迟,服务端下行消息时认为设备在线,实际上设备已经离线,无法收到;
  • 3)客户端收到了下行消息,但端上后续处理失败(比如落库失败,消息没有成功展示给用户)。

我们通过数据埋点统计得出,ACCS长连接的下行成功率在97%左右。

ACCS长连接的下行成功率的统计方法如下:

ACCS下行成功率 = 通过ACCS成功下行且客户端收到的消息量 / 服务端认为通过ACCS成功下行的消息量

有心急的同学就要问了,丢了3%的消息吗?

并没有!这3%的消息不会丢失,只是不保证及时触达给用户。

我们的消息同步模型是推拉结合模式,在用户拉取消息时会拉取到设备当前位点与服务端最新位点的所有消息,ACCS下行失败的消息会通过主动拉模式获取到,但客户端主动拉取消息的触发时机有限。

当前客户端主动拉取消息的触发时机主要有以下几个:

  • 1)用户冷启动app,主动同步消息;
  • 2)用户主动下拉刷新;
  • 3)app后台切换前台;
  • 4)收到一条推送消息,客户端发现新消息的位点跟本地最新的位点有gap,触发同步。

可见:上述主动同步消息的触发很大程度上依赖用户行为或者有没有收到新消息,难以保证消息及时到达。

如果是用户高频打开的IM软件,这样也不会有太大的问题。但是闲鱼app的活跃度较低,有时候甚至依赖IM消息拉活,而且一条延迟的消息触达可能导致用户错过一笔交易,闲鱼消息不允许有这样的延迟发生。

基于上述分析,我们先描述一个数据指标来反映现状。

通过上面的描述可知:ACCS消息并不全都是推下来的,也可能是主动拉下来的。如果是推,必定可以及时到达;如果是拉,则受限于用户行为。

拉的这部分消息,我们定义为ACCS消息补偿到达,然后计算ACCS消息补偿到达耗时,消息范围限定为服务端ACCS成功下行但是客户端通过主动拉取同步到的消息,以往的版本这个数据在60分钟左右。

注意:这个数据并不是消息触达到用户的耗时,因为如果在线转离线触达,拉取到消息的时间取决于用户行为(用户何时打开了app),但这个数据也能大致反映在线消息的到达延迟状况。

ACCS长连接的消息补偿到达耗时的统计方法如下:

ACCS消息补偿到达耗时 = 客户端通过拉获取到ACCS消息的时间 - 服务端ACCS下行时间

接下来本文将从长连接的重连和未达消息重发两个方面详细讲述我们是如何优化在线通道稳定性的,从而优化并保证消息的及时到达。

4、优化手段1:增加长连接重连机制

4.1 长连接为什么会中断?

有因必有果,我们先来分析下有哪些原因会导致连接中断。

对于IM这种场景下来说,通常可能有以下原因:

  • 1)用户设备断网;
  • 2)设备发生了网络切换;
  • 3)设备处于弱网环境,网络不稳定;
  • 4)设备网络正常,TCP连接由于NAT超时导致连接被运营商中断。

对于APP来说,如果是用户操作导致网络状态变化的情况,会有网络状态变化事件通知,这种情况可以监听事件并主动尝试重连。但现实中的大多数情况都是“意料之外”(正如上面列举的这些断网可能性一样)。

那么既然“意料之外”的断网无法预知,技术上可以如何有效的感知到各种异常状况呢?

PS:如果要透彻理解断网、弱网、TCP链接有效性,并不是本文能讲的清楚的,可以参照下面的资料深入理解一下,值得好好学习。

关于TCP链接本身的有效性问题,可以读以下两篇:

  1. 为何基于TCP协议的移动端IM仍然需要心跳保活机制?
  2. 不为人知的网络编程(十二):彻底搞懂TCP协议层的KeepAlive保活机制

关于移动网络的复杂性问题,可以从以下几篇入门的科普文章学习一下:

  1. IM开发者的零基础通信技术入门(十一):为什么WiFi信号差?一文即懂!
  2. IM开发者的零基础通信技术入门(十二):上网卡顿?网络掉线?一文即懂!
  3. IM开发者的零基础通信技术入门(十三):为什么手机信号差?一文即懂!
  4. IM开发者的零基础通信技术入门(十四):高铁上无线上网有多难?一文即懂!

关于移动弱网带来的各种问题、优化方案等,可以通过以下几篇系统学习一下:

  1. 现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障
  2. 移动端IM开发者必读(一):通俗易懂,理解移动网络的“弱”和“慢”
  3. 移动端IM开发者必读(二):史上最全移动弱网络优化方法总结
  4. 百度APP移动端网络深度优化实践分享(三):移动端弱网优化篇

4.2 心跳检测机制

像大多数链路保活场景一样,IM这种场景下最有效的检测手段就是心跳检测(如果你对TCP链路保活还没有什么概念,建议先读《为何基于TCP协议的移动端IM仍然需要心跳保活机制?)。

原理就是:客户端通过定时发送心跳包,服务端收到心跳包后再反馈给客户端,通过客户端和服务端这一来一去的配合,就可以实现客户服和服务端各自都能感知到连接是否中断。

从及时性效果来看:心跳间隔越短越好,而频繁的心跳检测势必会带来用户流量以及电量的损耗,所以我们的实现目标是如何尽可能少的心跳检测而又尽量及时地感知到长连中断的意外情况。

状态机+消息心跳队列:

在心跳协议设计上,要注意心跳包的核心目标是检测长连通道是否畅通,客户端主动上行心跳包且能收到服务端回包,就认为长连通道健康。所以心跳的上行消息以及回包的数据包应尽可能小。一般来说,通过协议头标识心跳包及响应即可(这样就能节省协议包大小)。

PS:关于心跳机制的入门文章可以详读《一文读懂即时通讯应用中的网络心跳包机制:作用、原理、实现思路等》。

4.3 心跳策略

心跳策略是实现我们上述目标的核心机制,本文仅简单列举几种心跳策略。

比如以下这几种:

  • 1)短心跳检测 初始状态连续 ping 3次 收到 ACK 后,可以认为进入稳定状态;
  • 2)常规固定时长心跳(根据app状态不同,频率可调Mid+,Mid-, Long);
  • 3)自适应心跳 根据设备网络状态变化自动适应的心跳间隔;
  • 4)冗余心跳,app后台切前台,主动心跳一次。

关于心跳策略的详细设计甚至可以单独写一篇文章,有兴趣的同学可以阅读以下推荐的文章继续深入研究。

5、优化手段2:消息ACK应答与重发机制

5.1 概述

为了解决上面的问题,我们同时也引入了消息ACK应答与重发机制。

整体思路是:客户端在收到ACCS消息并处理成功后,给服务端回一个ACK应答包,服务端下发ACCS消息时将消息加入重试队列,收到ACK应答包后更新消息到达状态,并终止重试。

整体设计流程图如下:

该方案的难点即重试处理器的实现设计,接下来我们将重点讲述这部分的详细设计。

5.2 重试队列存储设计

我们采用阿里云表格存储TimeLine模型来存储下行消息的到达状态。Timeline 模型是针对消息数据场景所设计的数据模型,它能满足消息数据场景对消息保序、海量消息存储、实时同步的特殊需求,在IM、Feed流等消息场景应用广泛。(关于TimeLine模型,这里有篇详细的文章可以学习一下《现代IM系统中聊天消息的同步和存储方案探讨

我们给每个用户设备定义一个TimeLine,timeline-id定义为userId_deviceId,sequenceId自定义为消息位点。

存储结构如下:

每通过ACCS成功下行一条消息,则插入到接收用户设备的TimeLine中,收到ACK后根据消息id更新消息到达状态。

同时由于重试动作只发生在下行消息后较短的一段时间内,所以我们设置一个比较短的全局过期时间即可,避免数据膨胀。

5.3 延迟重试设计

如上图所示:

  • 1)每通过ACCS下发一条消息,先插入到Timeline中,初始状态为未达,然后生产一条延迟N秒的延迟消息;
  • 2)每次消费到延迟消息后,读取tablestore中该消息的到达状态,如到达则终止延迟,否则继续;
  • 3)每次重试先判断设备是否在线,如果设备不在线,转发离线通道并终止重试,如果设备在线,则重推未到达的消息,并再次延迟N秒消费;
  • 4)每条消息的重试生命周期中用的同一条延迟消息,最多重试消费M次,超过次数不再重试并打日志埋点(后续可以监控这种情况并基于这个数据进行优化)。

5.4 延迟重发策略

延迟重发策略是指在重发流程中,如何选择合适的延迟时间来使得重发的效率最高。

不同用户在不同时间、地点所处的网络环境差别较大,网络恢复到稳定态所需要的时间也有差异,需要选用合适的延迟策略来保证重发效率。

最优的延迟策略的目标是在最短的时间内,使用最少的重发次数将消息投递成功。以下是几种可选的方案。

5.4.1)固定延迟时间:

要想找到最优的延迟策略,必须从数据中通过分析得到答案,天马行空的想象往往离实际相差甚远。

我们先采用固定的延迟时间(10s)最大重试6次来分析一波数据:

通过这组数据可以看到:有约85%的消息在40s内重发可以投递成功,还有12%的消息在达到最大重试次数后依旧没有收到ACK。在4次重试之后,第5次成功只有2.03%,第6次只有0.92%,继续重发的收益已经变得很低。

6次以后还有部分消息没有收到ACK,这部分消息如果用固定延迟时间策略,性价比很低,频繁重发浪费系统资源,我们需要继续改进策略。

5.4.2)固定延迟+固定步长递增:

考虑到部分用户的网络短时间无法恢复,频繁的短间隔重发价值不大,我们采用4次固定短间隔延迟N秒后,每次延迟时间都是上一次延迟时间递增固定步长M秒的策略。直到收到ACK、用户设备离线或者达到了最大延迟时间MAX(N)。

这种策略一定程度上可以解决固定延迟时间重发策略的问题,但如果用户短时间网络无法恢复,每次重发都要重新递增,也不是一种最优解。

5.4.3)自适应延迟:

设计流程图:

如上图:我们最终衍生出了自适应延迟策略。

自适应延迟是指:根据用户的网络状况,采取自动调整的延迟时间,以期望达到最高的重发效率。

具体是:新消息先通过4次固定N秒的短延迟来探测设备的网络状况,一旦网络恢复,我们将设备的N值清空(设备N值是指根据上几次重发经验,当前设备网络能回复ACK所需要的最短时间,默认情况该值为空,代表用户设备网络正常)。4次重发后依旧收不到ACK,我们尝试读取设备N值,如果为空,则取初始值,以后每次延迟都递增固定步长M,并在重发后更新当前设备的N值,直到消息收到ACK或者达到了最大延迟时间MAX(N)。

5.5 新老版本兼容性

需要注意的是老版本的app是不会回ACK的,如果下发给老版本设备的消息也加入重试队列,那此类消息将一直重试到最大次数才会终止,无端消耗资源。

所以我们设计在ACCS长连建立之后,客户端主动上行一条设备信息,其中包含app的版本号,服务端存储一定时间,在将消息加入重试队列之前,先校验接收者设备app的版本号,符合要求再加入重试队列。

6、 最终优化后的效果

消息重连重发方案上线后,我们上面定义的指标 ACCS补偿到达时间 从60分钟大幅降低至15分钟,降幅达75%。

从而印证了我们的技术分析,同时用户有关消息延迟的舆情反馈大幅下降,可见消息重发机制对保证用户消息及时到达成效显著。

7、未来展望

消息在线通道的稳定性优化至此已告一段落,未来我们将继续优化闲鱼消息的使用体验,包括基础功能的完善以及基础体验的提升。

基础功能方面:我们在近期的版本中已经支持了消息撤回、草稿功能,后续将逐步支持发送定位,会话分组、备注,消息搜索等功能。

基础体验方面:我们对消息的UI样式做了优化升级,并优化了app消息tab页的cpu及内存使用,后续将继续从流量、电量、性能方面继续优化消息的使用体验。

附录:参考资料

[1] 为何基于TCP协议的移动端IM仍然需要心跳保活机制?

[2] 不为人知的网络编程(十二):彻底搞懂TCP协议层的KeepAlive保活机制

[3] 现代IM系统中聊天消息的同步和存储方案探讨

[4] 现代移动端网络短连接的优化手段总结:请求速度、弱网适应、安全保障

[5] 移动端IM开发者必读(二):史上最全移动弱网络优化方法总结

[6] IM开发者的零基础通信技术入门(十二):上网卡顿?网络掉线?一文即懂!

[7] IM开发者的零基础通信技术入门(十三):为什么手机信号差?一文即懂!

[8] 移动端IM实践:实现Android版微信的智能心跳机制

[9] 融云技术分享:融云安卓端IM产品的网络链路保活技术实践

[10] Web端即时通讯实践干货:如何让你的WebSocket断网重连更快速?

本文已同步发布于“即时通讯技术圈”公众号。

同步发布链接是:http://www.52im.net/thread-3726-1-1.html

posted @ 2021-10-19 23:05 Jack Jiang 阅读(109) | 评论 (0)编辑 收藏

2021年10月11日

     摘要: 本文由作者“阿宝哥”分享,原题“你不知道的 WebSocket”,有修订和改动。1、引言本文将从基本概念、技术原理、常见易错常识、动手实践等多个方面入手,万字长文,带你一起全方位探索 WebSocket 技术。阅读完本文,你将了解以下内容:1)了解 WebSocket 的诞生背景、WebSocket 是什么及它的优点;2)了解 WebSocket 含...  阅读全文

posted @ 2021-10-11 14:35 Jack Jiang 阅读(95) | 评论 (0)编辑 收藏

2021年9月26日

     摘要: 本文由阿里闲鱼技术团队景松分享,原题“到达率99.9%:闲鱼消息在高速上换引擎(集大成)”,有修订和改动,感谢作者的分享。1、引言在2020年年初的时候接手了闲鱼的IM即时消息系统,当时的消息存在各种问题,网上的用户舆情也是接连不断。典型的问题,比如:1)“聊天消息经常丢失”;2)“消息用户头像乱了”;3)“订单状...  阅读全文

posted @ 2021-09-26 14:47 Jack Jiang 阅读(121) | 评论 (0)编辑 收藏

2021年9月13日

本文由阿里闲鱼技术团队今朝、有攸分享,本次有修订。

1、引言

闲鱼即时消息系统历经数代迭代,目前已能稳定的支撑亿级消息体量。

在此消息系统的建设过程中,我们经历了从简单到复杂、从困扰到破局,每一次的技术改变都是为了更好的解决当下业务所面临的问题。

本文分享的是闲鱼即时消息系统架构从零开始的技术变迁之路,以期更多的同行们在此基础上汲取经验,得到有价值的启发。

学习交流:

- 即时通讯/推送技术开发交流5群:215477170 [推荐]

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

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

本文同步发布于:http://www.52im.net/thread-3699-1-1.html )

2、系列文章

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

  1. 阿里IM技术分享(一):企业级IM王者——钉钉在后端架构上的过人之处
  2. 阿里IM技术分享(二):闲鱼IM基于Flutter的移动端跨端改造实践
  3. 阿里IM技术分享(三):闲鱼亿级IM消息系统的架构演进之路》(* 本文
  4. 阿里IM技术分享(四):闲鱼亿级IM消息系统的可靠性投递技术实践》(* 稍后发布

3、1.0版:业务初创期、最小化可用

3.1 技术背景

2014年启动闲置交易独立APP “闲鱼”,一期构建完成APP主链路,包含商品:发布→搜索→商品详情→IM会话→交易

作为初创app,业务需尽快上线验证效果,技术建设上需要完成闲鱼消息从无到有的系统搭建。

3.2 技术方案

作为即时通讯系统,最小化能力包含:

  • 1)消息存储:会话、摘要、消息;
  • 2)消息同步:推、拉;
  • 3)消息通道:长连接、厂商推送。

与一般IM会话模型不同的是,闲鱼会话以商品为主体,“人+人+商品”为要素构建会话。

因会话模型的差异,淘系已有的消息系统,短期内无法满足业务需求,而闲鱼完全自建消息系统耗时巨大。

为了保障业务高效上线,技术选型上最大化复用已有系统能力,避免重复造轮子。

所以,我们的技术方案是:

  • 1)数据模型与底层存储依赖淘系私信体系进行建设;
  • 2)消息数据获取上,客户端全量从服务端拉取消息数据;
  • 3)通讯协议使用来往SDK及mtop。

总体架构如下图,以此模式完成快速交付保障了业务最小化可用:

4、2.0版:用户量增速快、需要重建消息系统

4.1 技术背景

闲鱼用户量正快速突破100万,即时消息服务的调用量暴涨。在这样的背景下,用户反馈消息数据获取的卡顿、白屏成为常态,大量的消息Push发送下,系统告警频发。

造成这些问题的原因:1.0版的架构模式下,获取消息数据全量拉模式,客户端纯UI不做数据存储。

具体就是:

  • 1)当用户需要查看消息数据时,数据拉取成功与否取决于网络、数据访问速度,偶发性的造成卡顿、白屏;
  • 2)中心化的数据存储,读远大于写,高并发下,服务端负载过大。

针对第2)点:比如1W个用户同时在线聊天,按照当前架构并发拉取全量消息,估算5万QPS。不妨假设,同时在线聊天用户数10万时,对服务端压力可想而知。

4.2 技术方案

基于上述问题,我们决定重建消息系统架构,以应对未来更大的用户增量。

回归到IM系统的核心功能:

4.2.1)消息存储模型:

  • 1)会话模型:由owner、itemid、user、sessionType 来标识唯一会话,增加扩展属性支持个性化;
  • 2)摘要模型:作为用户会话视图,同一会话的不同用户可个性化呈现,由userid、sid标识唯一摘要;
  • 3)消息模型:由sender、消息内容、消息版本、sid组成。sid+消息版本唯一确定一条消息;
  • 4)指令模型:是一种双端约定,由服务端下发,客户端执行的指令集。如免打扰指令、删除指令等。

4.2.2)消息通道:

1)在线通道:使用淘宝无线ACCS长连接提供的全双工、低延时、高安全的通道服务;

2)离线通道:使用淘宝消息推送平台AGOO. 其屏蔽了各主流厂商对接的复杂度,直接对业务系统提供服务。

4.2.3)消息同步模型:

1)客户端建立数据库,存储消息数据:当消息数据存储在本地设备上,消息同步从全量拉取优化为全量+增量同步结合的模式。

增量和全量同步具体指的是:

  • a. 增量同步:客户端存储消息位点信息,通过与服务端最新位点比较,仅同步增量消息;
  • b. 全量同步:当用户卸载重装或位点gap过大时,客户端全量拉取历史消息数据,进行端上数据重建。

2)服务端建设个人消息域环(收件箱模型):以和客户端进行增量数据同步。同时,1.0版本架构中存在的读多写少的问题,通过个人域环的写扩散来平衡读写压力。

下图为一条消息从发送到接收的过程以及服务端和客户端的执行流程:

如上图所示:假设Ua给Ub发送一条消息,消息写扩散至Ua和Ub的各自的域环中:

  • 1)当客户端online时,接收到推送的消息位点=当前端上域版本+1,本地消息数据库merge即可;
  • 2)当客户端offline时,仅进行离线推送通知,当用户重新上线时,进行数据同步,由服务端判断触发增量同步还是全量同步。

针对第2)点,具体逻辑是:

  • 1)如果域环版本差值小于阀值,增量同步后,进行本地消息数据库merge;
  • 2)当域环版本差值大于阀值,进行全量消息拉取,做端上数据重建。

整个同步逻辑基于闲鱼的即时消息域环,域环可以看作是有着固定容量的用户消息收件箱,给一个用户发送的所有消息都会同步到他的域环中。

具体就是:

  • 1)域环存储:域环需要支持高并发数据读写,使用阿里分布式KV存储系统tair来实现;
  • 2)域环容量:为减少全量消息同步,以用户下次进入闲鱼需要同步的平均消息量来规划个人域环容量。同时利用FIFO循环覆盖历史数据;
  • 3)域环版本:用户当前消息位点,在消息进入个人域环时通过tair的counter实现域环版本严格连续递增,用于全量、增量同步判断。

上述建设完成后,闲鱼具备了自己独立的即时消息系统,当下遇到的问题得到了缓解,用户体验度有大幅提升。

5、3.0版:随着业务快速发展,系统稳定性需得到保障

5.1 技术背景

随着闲鱼业务生态的丰富,IM会话与消息内容类型不断扩展,同时在用户量的快速增长下,用户反馈消息收不到、消息延迟等舆情问题日渐突出。

5.2 问题分析

问题1:闲鱼app进程无有效保活机制,app退到后台后进程很快就会被系统挂起,导致长连接中断。此时消息推送走厂商通道,而厂商通道的实时性较差,且对消息推送的优先级设定有差异,从而造成用户感知消息延迟。

问题2:accs在线消息推送时,平均延时较短,但存在假连情况。而且目前的消息推送链路无ack机制,造成服务端以为消息发出去了但实际上客户端并没有收到,用户下次打开app后才能看到消息,用户感知消息延迟。

PS:造成假连接的原因主要是用户退到后台,accs长连中断,但是设备状态更新有延时。

问题3:目前消息同步的推模式(accs push)、拉模式(mtop),客户端未做隔离,异步进行处理,导致在某些极端情况下消息数据库处理异常,引发消息丢失。

如:某用户上线后连续收到多条消息,其中一条触发域黑洞,在进行消息同步端上数据重建时,小概率处理出错。

问题4:大部分线上消息问题发现靠舆情反馈,如消息错乱,出问题后系统无感知、无补救措施且排查困难,仅能跟随版本做修复。

问题5:业务不断丰富,孵化出基于消息系统的服务号及小程序内容营销、消息群组等,各类消息发送链路共用域环与数据存储,造成稳定性问题。

如:个人域环的消息包括IM聊天和营销消息,IM聊天由用户触发,需要保证强到达;而营销消息一般是由系统通过班车等方式批量发送,消息量级大,tps高,影响IM服务稳定性。

5.3 解案决方案

基于上述分析,我们逐个问题进行专项解决。

1)消息重发与推拉隔离:

如上图所示:

  • a. ACK:保障消息及时到达。服务端下行accs消息时,将消息加入重试队列并延迟重试,客户端在收到accs消息并处理成功后,给服务端回一个ack,服务端收到ack后更新消息到达状态,并终止重试,以此避免设备假连或网络不稳定的情况;
  • b. 重发:根据延迟重发策略决定何时重发消息,保障消息确定性到达。自适应延迟重发策略是指新消息先通过4次固定N秒的短延迟来探测设备的网络状况,然后根据网络状况来递增固定步长M的延迟策略,这种策略可以保障在最短的时间内,使用最少的重发次数将消息投递成功;
  • c. 消息队列:端上引入消息队列,按顺序处理消息,保证消息处理的准确性。同时进行推拉隔离,保障队列有序消费,解决了复杂状况下并发处理消息数据合并出错的问题。

2)数据存储拆分:

闲鱼每天发送的即时消息中有一半以上是营销消息,营销消息的发送具有明显的波峰波谷流量,高峰期会导致消息数据库抖动,影响IM消息。我来对消息、摘要、域环存储做业务隔离,以适应不同业务场景对稳定性不同的要求。

具体做法是:

  • 1)IM消息需要极高的稳定性保证,其消息及摘要继续使用mysql存储;
  • 2)营销消息存储周期短,稳定性要求低于IM,采用Lindorm存储;
  • 3)域环做实例级别隔离,保证IM域环的容量不会被其他消息占用,从而影响到消息同步。

PS:Lindorm是一种多模型的云原生数据库服务,具有成本低、自定义TTL、容量横向扩展等优势。

3)线上问题发现与恢复:

保障稳定性的关键要素是做好各种核心指标的监控,而监控首先要有数据来源,对服务端+客户端的关键链路节点埋点,基于集团UT、SLS,通过blink进行实时清洗、计算,最终形成统一规范的日志数据落至SLS,以供实时监控及链路排查。

消息系统的核心目标是保障用户消息发的出、收得到且及时收到,所以我们通过计算发送成功率、到达率、消息延迟来监控系统的稳定性。

此外,为了解决用户舆情排查困难的问题:

  • 1)我们设计了一套指令集,通过约定指令协议,服务端向指定用户下发指令,客户端执行对应指令进行异常数据上报,提高排查效率;
  • 2)扩展了强制全量同步、数据校正等指令,定向修复用户消息数据问题,相较以往出现严重bug只能让用户卸载重装解决,这种方式显然对用户是更友好的。

经过一系列专项治理,技术类舆情下降50%,从0到1建设了消息稳定性体系,用户体验进一步提升。

6、展望未来

闲鱼作为电商交易APP, 其中IM是交易的前置链路,IM的产品体验极大影响用户交易效率。

前段时间进行用户调研,从闲鱼IM的NPS低于预期(NPS是用户忠诚度衡量指标 = 推荐者%-贬损者%)。

从用户反馈来看:

  • 1)部分用户对产品功能有较强烈的诉求,诸如消息搜索、分组等;
  • 2)大部分用户对发送消息过程中的违规问题难以理解;
  • 3)仍有较多舆情反馈消息收不到或延迟。

映射到目前闲鱼的即时消息系统上,我们的系统架构依然有很多需要持续改进的地方。

典型的如:同步协议冗余,在需求迭代过程中容易引发问题、有效保活机制的缺失对消息即时送达的影响、小众机型离线消息收不到、多年的数据积累在线库臃肿等问题,影响着闲鱼业务迭代速度与NPS。

作为技术团队,下一步将提升NPS作为核心技术目标,闲鱼的即时消息系统4.0版架构正在路上 ......

附录:更多相关文章

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

阿里钉钉技术分享:企业级IM王者——钉钉在后端架构上的过人之处

现代IM系统中聊天消息的同步和存储方案探讨

阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史

阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路

来自阿里OpenIM:打造安全可靠即时通讯服务的技术实践分享

钉钉——基于IM技术的新一代企业OA平台的技术挑战(视频+PPT) [附件下载]

阿里技术结晶:《阿里巴巴Java开发手册(规约)-华山版》[附件下载]

重磅发布:《阿里巴巴Android开发手册(规约)》[附件下载]

作者谈《阿里巴巴Java开发手册(规约)》背后的故事

《阿里巴巴Android开发手册(规约)》背后的故事

干了这碗鸡汤:从理发店小弟到阿里P10技术大牛

揭秘阿里、腾讯、华为、百度的职级和薪酬体系

淘宝技术分享:手淘亿级移动端接入层网关的技术演进之路

难得干货,揭秘支付宝的2维码扫码技术优化实践之路

淘宝直播技术干货:高清、低延时的实时视频直播技术解密

阿里技术分享:电商IM消息平台,在群聊、直播场景下的技术实践

阿里技术分享:闲鱼IM基于Flutter的移动端跨端改造实践

阿里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消息系统的架构演进之路

>> 更多同类文章 ……

本文已同步发布于“即时通讯技术圈”公众号。

同步发布链接是:http://www.52im.net/thread-3699-1-1.html 

posted @ 2021-09-13 15:12 Jack Jiang 阅读(134) | 评论 (0)编辑 收藏

2021年9月7日

     摘要: 本文引用自“ 豆米博客”的《JS实时通信三把斧》系列文章,有优化和改动。1、引言有关Web端即时通讯技术的文章我已整理过很多篇,阅读过的读者可能都很熟悉,早期的Web端即时通讯方案,受限于Web客户端的技术限制,想实现真正的“即时”通信,难度相当大。传统的Web端即时通讯技术从短轮询到长连询,再到Comet技术,在如此原始的HTML标准之下,为了实现...  阅读全文

posted @ 2021-09-07 10:47 Jack Jiang 阅读(122) | 评论 (0)编辑 收藏

Jack Jiang的 Mail: jb2011@163.com, 联系QQ: 413980957, 微信: hellojackjiang