写点什么

转转 push 的演化之路

  • 2022 年 7 月 29 日
  • 本文字数:2380 字

    阅读完需:约 8 分钟

一、简介

从 0 开始讲讲转转 push 系统的迭代过程,以及遇到的常见问题的解法。


顾名思义,push 就是就是借助厂商通道把消息发送给用户的一种方式,一般用于用户的召回和活动触达,和 IM(即时通信)还是有一些区别,不在此处赘述。

1.1 名词解释

业务属性: 运营、业务、功能类推送


推送范围: 月活、全量、定向推送、个性化推送


目标端:一般是安卓、ios 客户端


通道:小米、华为、魅族、apns 等手机厂商的常驻连接


token: 用于设备的唯一标识,由 APP 本身生成


devicetoken:用于推送的唯一标识,一般由厂商提供


推送量:推送消息的数量


到达率:消息到达手机的数量/推送量


点击率:用户点击率/推送量

1.2 现有架构


  • 现有的架构支持后台推送、业务推送以及个性化推荐推送。


后台推送


一般会有标准的格式,特点是时间短、推送量大,比如 8 点秒杀活动。


业务推送


一般都是业务触发,特点是实时性强、优先级高,如订单支付消息。


个性化推送


经常会和用户画像相关,特点是策略复杂、内容多样,需要有风控管理,如猜你喜欢等推荐策略。

二、项目迭代的过程

2.1 缘起:PM 想推送运营活动

  • 步骤:

  • 1)PM 从大数据平台上导出一部分用户集合

  • 2)RD 写程序调用 push 接口

  • 问题:

  • 1)N 个 PM 都有需求,RD..........

  • 2)8 点有一个突发情况,9 点来一波

  • 3)每周末都要活动,推送

  • 解决方案:

  • 1)搭建一个后台,支持根据用户 ID 上传,解放开发资源

  • 2)支持按照时间推送,支持文案可配

  • 3)支持安卓、IOS 分端推送

  • 遗留的问题:

  • 问题描述:

  • PM 上传了一个浏览过手机类目用户的数据集合,数据量太大,上传超时

  • 解决方案?

  • PS:用户量大概在 1000w 左右+,大约 300M 左右的文件?

  • 提示:

  • 1)上传的时间大约在 1 分钟左右, 需要联系运维设置最长的链接时间,否则 nginx 会主动断开

  • 2)上传由同步上传,改成进度条的方式,让上传者可以看到进度

  • 3) 上传和数据处理分开(我们当时是边上传,边解析文件比较慢)

2.2 重大节日,希望能够通知到近期的活跃用户

2.2.1 实时推

  • 问题描述:

  • 重大节日,推送全量用户、月活、周活数据,每次只是文案不同,PM 都需要跑大数据系统,效率太低,当天数据不可获得,平均推送需要 1 个多小时。

  • 要求:

  • 1)1 亿的数据能够在一小时内推送完毕

  • 2)要覆盖到某一个周期内的用户(比如一个月)

  • 3)支持预览,支持暂停

  • 分析-数据量(以 2000w 月活为例):

  • 1) 全量用户认定为近 3 个月(90 天)内访问过转转的用户

  • 2) 预估所有设备数量在 5000w 左右

  • 3) 预计占用的空间为 5G

  • 分析-性能(以 2000w 月活为例):

  • 1) 老系统 push 的平均 QPS 是 2000

  • 2) 2000W/2000/60/2=83~=1 小时 20 分钟,希望能够在 12 分钟内推送完毕(一个小时推送 1 亿的指标)

  • 难点分析:

  • 1) 数据做到准实时,怎么算准实时

  • 2)2000 千万的数据 12 分钟内推送完毕,QPS~=2.7w, 如何让性能提升 13.5 倍(2k 提升到 2.7w 的并发)

  • 解决方案:

  • 1) 数据的准实时

  • 实时接收 kafka 日志消息,每分钟把清洗的数据进行合并

  • 2)需要存储的数据要素

  • a) 用户的 token 信息(注意不是 devicetoken)

  • b) 此 token 的活跃时间(时间戳)

  • 3)用户数据存储选型



最终选择 redis 的 zset 进行存储


4)如何提高发送性能


首先分析之前之所以慢的原因:


1) 单线程发送


2) 受到厂商通道的限制,单接口耗时 100ms+(IOS 通道)


解决方案:


1)区分安卓、IOS 单独发送,原始程序只负责从 redis 拿到数据后拼装成固定结构(简单拼接操作速度很快)


2)把数据推送到 MQ 中(可以不用 MQ 吗?)


3)多个消费订阅者,进行消费(容易扩展),通过厂商 通道推送出去。


注意:IOS 通道,我们用的 pushy 开源工具,特定情况下无法持续推送消息,需要定时检查,重新创建通道


  • 最后的效果:

  • push 推送的 QPS 达到 3w+,推送能力提升的同时,也引发了以下问题。

2.2.2 业务服务器扛不住瞬时流量

问题描述:


当 push 的推送能力上去了之后, 用户的瞬时访问问题随之而来


1)瞬时的流量高峰,导致超时增多


2)部分请求到达性能瓶颈,超时增多,页面打不开~,见下图



解决办法:


1)最简单的办法:加机器


2)业务接口多线程、服务治理,消峰(ratelimit)


3)app 核心功能增加缓存,保证不会出现白屏的情况


4)减少活动路径。(一般 push 都会落地到某一个活动页面。但是正常打开 push,都会先进入首页,再跳转到活动页面。给 push 的消息增加特殊埋点,如果是此类 push 消息,就直接跳转到特定页面,减少中间环节。)

2.3 AB 实验室

  • 问题描述:

  • 有一天晚上 9 点推送了一个运营类的 push,发现居然点击率超级高,是文案优秀?还是流量高峰?

  • 要求:

  • 1)存在多个推送文案,系统能够择优选择点击率最好的进行推送?

  • 解决方式:

  • 1) 加入 AB 测的能力,先进行少量用户推送,根据 AB 的效果,择优推送

2.4 多通道来临

  • 新的问题:

  • 之前安卓的通道我们仅有小米通道+个推(个推达到率一般,做托底), 如果我们向华为手机推送消息,也是通过小米通道是很难到达的。

  • 要求:

  • 1)希望能够把大厂的厂商通道都接进来

  • 2)推送的消息能够根据用户最后登录的通道进行优化推送

  • 3)速度不能慢下来

  • 解决方式:

  • 1) 搭建 tokens 服务,能够批量判定 devicetoken 的最后使用的厂商(需要依赖转转客户端上报)

  • 2) 分库分表的方式进行存储

  • 3) 数据热备到缓存中

  • 效果:

  • 1) 当年统计能够提高 10%的达到率

  • 2.5 实时监控


  • 一般的监控维度包含:

  • 产品线:转转、找靓机等等

  • 客户端:安卓、IOS

  • 指标: 发送、到达、点击的数量和比例

  • 数据对比: 模板、周期

  • 通道: 小米、华为、vivo、apns


三、总结

现状:


1) 推送月活 10 分钟


2) 支持暂停、预览,实时查看推送数据量


3) 支持提前 AB 看效果


4) 支持不在线,微信通知


5) 支持防打扰


6) 支持优先级和厂商高优通道


提高速度:


预加载+缓存+多线程+合理的数据结构+批量处理+合理布局+特殊埋点


折中方案:


异步上传、限流控制、降级处理、分层解耦、补偿通知




作者简介


王计宽,转转平台业务负责人。


转转研发中心及业界小伙伴们的技术学习交流平台,定期分享一线的实战经验及业界前沿的技术话题。


关注公众号「转转技术」(综合性)、「大转转 FE」(专注于 FE)、「转转 QA」(专注于 QA),更多干货实践,欢迎交流分享~

用户头像

还未添加个人签名 2019.04.30 加入

转转研发中心及业界小伙伴们的技术学习交流平台,定期分享一线的实战经验及业界前沿的技术话题。 关注公众号「转转技术」,各种干货实践,欢迎交流分享~

评论

发布
暂无评论
转转push的演化之路_push_转转技术团队_InfoQ写作社区