请选择 进入手机版 | 继续访问电脑版

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

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


1、引言


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

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

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

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

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

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

cover-opti.png

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

2、系列文章


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


3、通信链路类型的划分


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

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

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

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

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

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

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

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

4、消息系统架构概览


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

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

  • 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、厂商、设备、用户、承接页这几个环节。具体如下图所示。

2.png

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

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

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

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


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

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

这对应推送的两个阶段:

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

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

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

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

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

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

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

8、我们的技术优化手段


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

8.1agoo受理率优化


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

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

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

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

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

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

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

4.png

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

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

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

那就继续优化呗:

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

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

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


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

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

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

为什么会这样呢?

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

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

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

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

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

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

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

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

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

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

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

8.3Push点击率优化


通过优化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系统的消息时序一致性?

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

上一篇:IM开发基础知识补课(十):大型IM系统有多难?万字长文,搞懂异地多活!下一篇:基于实践:一套百万消息量小规模IM系统技术要点总结

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

推荐方案
评论 5
补充一点文章中未提及的,影响Android设备推送展示率和点击率另一个重要的因素就是,推送渠道(NotificationChannel)相关配置的规范程度。
规范使用「通知渠道」,可以更细粒度地划分应用内通知的场景,可以单独控制每种场景对用户的干扰程度,降低对用户的打扰,从而提高用户体验。
具体可以看我以前写的一篇文章:https://www.jianshu.com/p/38d6e5c5d6f4
引用:椎锋陷陈 发表于 2021-11-16 10:40
补充一点文章中未提及的,影响Android设备推送展示率和点击率另一个重要的因素就是,推送渠道(Notification ...

这个厂商推送还要进行分类,真是被厂商给玩坏了
引用:JackJiang 发表于 2021-11-16 11:56
这个厂商推送还要进行分类,真是被厂商给玩坏了

私以为厂商限额其实只是第三方厂商的“懒政”,怕所有的推送都走厂商推送通道有点承受不住,所以才推送消息总量进行限制。
引用:椎锋陷陈 发表于 2021-11-16 13:42
私以为厂商限额其实只是第三方厂商的“懒政”,怕所有的推送都走厂商推送通道有点承受不住,所以才推送消 ...

反正他们想怎么弄就怎么弄
写得真好
签名: 陈俊
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部