转转千万级用户量消息推送系统的架构演进之路

本文由转转平台业务负责人王计宽分享，原题“转转push系统的演进之路”，下文有修订和重新排版。

1、引言

顾名思义，push就是就是借助厂商通道把消息发送给用户的一种方式，一般用于用户的召回和活动触达，和即时通讯IM在业务上稍有区别，但技术逻辑上是相通的，不在此处赘述。

本文将从0开始讲讲转转千万级用户量消息推送系统的架构演进和迭代过程，以及遇到的常见问题的解法，希望能带给你启发。

技术交流：

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

- 开源IM框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）

（本文已同步发布于：http://www.52im.net/thread-4852-1-1.html）

2、术语解释

以下是本文涉及到的一些技术术语的解释：

1）业务属性：运营、业务、功能类推送；
2）推送范围: 月活、全量、定向推送、个性化推送；
3）目标端：一般是安卓、ios客户端；
4）通道：小米、华为、魅族、apns等手机厂商的常驻连接；
5）token：用于设备的唯一标识，由APP本身生成；
6）devicetoken：用于推送的唯一标识，一般由厂商提供；
7）推送量：推送消息的数量；
8）到达率：消息到达手机的数量/推送量；
9）点击率：用户点击量/推送量。

3、当前架构概览

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

以下是相关推送业务的特点：

1）后台推送：一般会有标准的格式，特点是时间短、推送量大，比如8点秒杀活动；
2）业务推送：一般都是业务触发，特点是实时性强、优先级高，如订单支付消息；
3）个性化推送：经常会和用户画像相关，特点是策略复杂、内容多样，需要有风控管理，如猜你喜欢等推荐策略。

4、技术背景——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）上传和数据处理分开（我们当时是边上传，边解析文件比较慢）。

5、希望重大节日能够即时通知到活跃用户

5.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）需要存储的数据要素：用户的token信息（注意不是devicetoken）；此token的活跃时间（时间戳）；
3）用户数据存储选型。

最终选择redis的zset进行存储。

5.2 如何提高发送性能

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

1）单线程发送；
2）受到厂商通道的限制，单接口耗时100ms+(IOS通道)。

解决方案：

1）区分安卓、IOS单独发送，原始程序只负责从redis拿到数据后拼装成固定结构（简单拼接操作速度很快）;
2）把数据推送到MQ中（可以不用MQ吗？）;
3）多个消费订阅者，进行消费(容易扩展)，通过厂商通道推送出去。

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

最后的效果：push推送的QPS达到3w+，推送能力提升的同时，也引发了以下问题。

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

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

1）瞬时的流量高峰，导致超时增多；
2）部分请求到达性能瓶颈，超时增多，页面打不开~,见下图。

push落地效果：

解决办法：

1）最简单的办法：加机器；
2）业务接口多线程、服务治理，消峰（ratelimit）；
3）app核心功能增加缓存，保证不会出现白屏的情况；
4）减少活动路径。（一般push都会落地到某一个活动页面。但是正常打开push，都会先进入首页，在跳转到活动页面。给push的消息增加特殊埋点，如果是此类push消息，就直接跳转到特定页面，减少中间环节。）