转转 push 的演化之路

一、简介

从 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），更多干货实践，欢迎交流分享~