导读：短视频 Push 系统是一套支持百度内多款 app 及多业务场景的分布式 Push 系统，目前支撑着好看视频，直播，度小视，好看大字版等 app 的推送业务，提供基于用户基本特征的个性化推送，热门活动和热点事件的运营推送，基于关注关系或订阅关系的业务实时推送等场景的支持。旨在通过个性化推荐系统及运营编辑方式稳定高效的给用户通知栏消息推送自己喜欢的内容信息从而达到提高用户活跃度，提升用户留存的业务目标。

全文 5886 字，预计阅读时间 15 分钟。

背景：

在这个信息爆炸的互联网时代，能够及时和准确获取信息是当今社会要解决的关键问题之一，Push 技术改变了传统的靠"主动拉"获取信息的方式，而是变成了信息主动寻找用户的方式，更适合在移动网络中满足用户个性化信息的需求。本文主要通过介绍短视频 Push 系统的设计和实现以及系统的不断优化，从而向大家讲述亿级数据量的 Push 系统的建设经验。

名词解释：

消息推送(Push)：通知栏消息推送，由服务端发起推送，在用户设备的锁屏界面、通知栏、APP 角标等位置展现的消息内容。

个性化 Push：通过用户画像和推荐模型挑选用户感兴趣的物料的 Push。

运营 Push：由运营人员在 Push 后台手动编辑物料发送的 Push（如：热门活动和热点事件等推送）。

实时 Push：根据用户在 app 产生互动操作（如：关注、点赞、评论等）或直播开播需要发送开播提醒时对时间要求相对精确的实时发送的 Push。

一、了解系统

1.1 系统简介

随着百度旗下短视频业务不断发展，app 也有上亿级别的季活用户量。Push 系统每天会给 app 的季活用户进行 n 条个性化推送和不固定条数的热门活动和热点事件运营推送，需要处理的数据量和并发量是系统设计需要考虑的重要问题，此外根据不同地域的用户群每天会发上百条的地域推送和大量的关注关系等实时推送，这对系统的稳定性要求也是很严格的，众所周知 Push 是一种很有效的拉活手段，其系统的稳定性重要程度可想而知。

1.2 系统全貌

Push 系统服务于好看视频，直播，度小视，好看大字版等业务。系统会实时订阅更新视频物料信息和用户属性信息，保障构建 Push 消息体时信息的准确性，会在凌晨请求推荐服务进行个性化物料的召回，然后根据运营 Push 和个性化 Push 的时间点创建 Push 任务，任务创建完成后会提前半个小时进行任务的预处理操作(保障 Push 能按时间尽快的发送)，用户互动消息和直播开播提醒等实时 Push 是通过 api 调用实时把要推送的内容发送给 Push 预处理服务。预处理完成将结果写进 redis 队列中，发送服务根据任务的优先级发送信息给云 Push 中台，云 Push 中台调用厂商代理 or 自己的长链接服务将 Push 信息发送到用户手机上。

总体架构如下图所示：

1.2.1 Push 核心架构各模块简介

1.物料中心：存储 Push 时需要的视频物料信息，包含 Push 的标题，描述，物料图片及状态等信息，订阅 B 端视频变更消息队列实时更新。

2.用户中心：存储 Push 需要的用户基本信息及 Push 系统特有的一些用户属性（如：1.预估用户活跃时间。2.预估用户首末条个性化 Push 时间等），客户端上报用户信息实时更新。

3.个性化召回：每天凌晨 1 点开始对季活用户进行个性化物料召回用于白天个性化 Push 的发送。

4.realtime-api 服务：实时写入预处理队列进行数据预处理及发送操作，用于实时 Push 等场景。

5.频控服务(ufc)：防止打扰用户，分天级别和小时级别两种。天级别的频控设置，一个用户一天内设置最大 Push 条数。小时级别，每个用户每半小时内最多收到 1 条 Push。

6.预处理服务：提前半小时对入库的任务进行切分，消息构造和入 Push 队列等处理，保障 Push 任务按时发送。

7.发送服务：根据任务的发送时间及任务的优先级从 Push 队列中获取相应厂商的任务将任务根据厂商的 ups 和 qps 进行切割后发送给云 Push。

8.回执服务：根据各厂商的到达回执记录相关日志，用于数据统计及实时监控报警。

9.控制中心(pcc)：重要 Push 功能的可视化配置系统。

Push 核心架构各模块依赖图如下：

1.3 系统数据流

1.3.1 系统整体数据流

客户端上报用户信息及一些用户行为的打点日志到数据中心，数据中心根据客户端打点产出相应的数据表，策略根据数据中心产出的数据表产出视频物料、Push 发送用户集和代理配额用户集，架构侧根据策略模型进行 Push 物料的召回并进行任务创建和发送将信息发送给 Push 中台，Push 中台发送给各厂商代理或长链接并产出 Push 相关数据表，厂商感知 Push 到达后发送回执消息给内部服务，架构根据到达回执记录日志并上报数据中心完成相关报表的产出。如下图所示：

客户端：通过 Push sdk 完成 Push_token 的绑定，上报用户基本信息及用户行为打点日志。

数据中心：根据业务打点产出活跃用户表、用户行为表和相关业务报表。

Push 策略：天级别产出 Push 物料并根据用户画像产出个性化 Push 物料。

Push 架构：凌晨进行个性化 Push 物料召回，定时进行任务发送并处理厂商的到达回执。

云 Push 中台：将 Push 任务发送给各厂商代理或长链接并产出 Push 基础数据表。

厂商代理：负责将各自厂商的 Push 任务发送到用户设备并发送到达回执。

1.3.2 Push 到达回执数据流

Push 到达回执分三种，各安卓代理厂商回执，Ios 回执和长链接回执，都由 Push 中台服务接收然后写进消息队列，架构侧的 Push-arrive 服务消费消息队列，1.实时统计计算并将数据写入 Redis 供实时统计报表使用，1.记录本地 Log，采集后做实时监控和报警，并上传到数据中心产出相关统计报表、Push 物料候选集，此外还会产出 Push 的点展样本用作 Push 模型的训练。

如下图所示：

二、系统迭代及优化之路

2.1 定时预估个性化 Push 首末条发送时间

2.1.1 背景

原逻辑所有用户每天首条个性化 push 的时间为 6:30，最后一条个性化 Push 的时间为 21:45。而每个用户起床、入睡时间不同，不同时间对接收到的 Push 敏感度也不同，根据用户习惯选择时间发送，可以提高 Push 的点击率。

2.1.2 服务设计

通过用户的使用习惯预估不同用户每日的首末条发送时间，达到用户在想看手机的时候准时给他 Push 他感兴趣的内容。显而易见服务的难点在于怎么预估用户什么时间比较空闲会看手机，大致逻辑如下，首条发送时间预估，统计 7 天内用户在[5:30, 6:00]时段内的首次活跃天数，若大于 1，则此用户的首条个性化发送时间由 6：30 调整为 5:30；非上述区间，则统计 7 天内该用户在[5:30, 6:30]时段内的首次活跃天数，若大于 1，则此用户的首条个性化发送时间由 6：30 调整为 6:00；剩下的用户发送时间仍为 6:30；末条发送时间预估，统计 7 天内用户在[22:15, 22:45]时段内的首次活跃天数，若大于 1，则此用户的首条个性化发送时间由 21:45 调整为 22：15；非上述区间，则统计 7 天内该用户在[22:15 23:59]时段内的首次活跃天数，若大于 1，则此用户的首条个性化发送时间由 21:45 调整为 22:45；剩下的用户发送时间仍为 21:45；如下图所示：

2.2 Push 系统用户分群服务优化

2.2.1 背景

此服务产出 Push 所需要的各种用户集合全量用户、个性化用户、兴趣用户、地域用户等，统称为用户包）用户包的产出依赖于不同的上游，包括用户中心、策略、数据组等，随着业务的迭代，存在以下几个问题：

1）缺乏统一管理，大多为部署在物理机上的定时脚本，存在单点问题，数据产出的监控、报警分散。

2）用户包的存储依赖物理机及 hadoop 集群，发送过程需要通过 ftp、afs 文件将用户包全量加载到内存，全量单任务耗时 30s 左右，影响时效性。

3）每种类型用户包都进行了单独的存储，存储资源存在浪费。

4）运营多选用户包时，加载重复的用户标识浪费内存资源，去重过程影响时效性。

5）直播召回模块重启时加载关注用户包及处理逻辑过程时间较长，影响上线效率及服务可用性，单机重启需 20 分钟。

2.2.3 服务设计

2.2.3.1 新老架构对比

原架构

新架构

1）为区别当前架构中基于物理机 ftp、afs 集群的用户包，使用用户群来表示符合某个单一维度特征的用户集合。

2）用户群的注册和管理通过 amis 平台统一配置，每个用户群拥有一个唯一标识。

3）用户群采用 bitmap 的方式进行表示及存储，bitmap 中每一位即表示一个用户，每个用户群都可以用一个 bitmap 来表示。

4）将 Push 服务中原有的用户包地址替换为用户群标签，多个用户群之间支持逻辑运算，用逻辑表达式表示。

5）发送过程中首先通过用户群标签的逻辑表达式查询用户群服务，获取一个最终要发送用户的 bitmap；再通过 bitmap 从用户群服务中批量获取 用户标识，流式处理并发送。

2.2.3.2 用户群管理设计

用户群配置：

1）配置层通过 amis 平台进行用户群的统一管理，以任务形式存于 mysql 中，支持用户群标签、用户包产出地址、更新频率、重试次数等配置；

2）调度层针对每个任务进行抢占式定时调度，将抢到的任务发给服务层执行；

3）服务层获取到任务，开始建库过程：

1、根据用户包地址拉取远程文件，成功则继续向下，失败则修改执行记录表任务状态及重试次数；

2、加载文件中的用户标识，计算对应 crc64/fnv64 值，并将结果映射存储在 redis 中（k：crc64/fnv64，v：用户标识）；

3、计算当前用户群的 bitmap（RaoringBitmap 算法），并将结果存储在 redis 中（k：用户群标签，v：用户群 bitmap）。

2.2.3.3 在线服务交互设计

在线服务交互流程：

1）Push 任务通过用户群标签来指定发送用户集合（amis/定时任务写入 mysql），多个标签使用逻辑表达式表示；

2）Push 服务层获取发送任务后，使用标签表达式请求用户群在线服务；

3）用户群在线服务根据逻辑表达式，从 redis 中读取出所有用户群标签的 bitmap，进行逻辑运算，得到最终发送用户群的 bitmap，返回给 push 服务层；

4）Push 服务层遍历 bitmap，按位获取 crc64/fnv64 值，批量请求用户群服务；

5）用户群服务从 redis 将 crc64/fnv64 映射回对应用户标识，返回给 Push 服务层。

2.3 Push 系统频控服务(ufc)优化改造

2.3.1 频控服务主要有如下功能：

1）基础功能限制一个用户在 30 分钟内不能收到两条 Push 消息，一天内 Push 总条数不能超过 max 条

2. 结合策略的提供的白名单数据，时间段频控，用户标识+推送类型的权重策略数据，到达回收数据，进行个性化频控

3. 永久 PushType 和用户标识 白名单功能，针对这类 PushType，用户标识不进行频控

2.3.2 背景

1. ufc 目前通过 hash（用户标识）的值取 mod 的形式分配固定的物理存储频控数据，固定了分配服务器个数，服务器 ip，不容易扩展，且扩展后会影响当天的用户频控数据，扩展上线大约 1 个小时。

2）推送类型、用户标识白名单经常变化的配置采用配置文件形式，每次改动上线耗费时间长。

3. 服务混合部署物理机，与其他服务竞争资源，会影响或者受到其他服务的影响，服务不稳定。

2.3.3 服务设计

动态扩容，一致性 hash 算法

1. 首先求出服务器（节点）的哈希值，并将其配置到 0～232 的圆（continuum）上。

2. 然后采用同样的方法求出存储数据的键的哈希值，并映射到相同的圆上。

3. 然后从数据映射到的位置开始顺时针查找，将数据保存到找到的第一个服务器上。如果超过 232 仍然找不到服务器，就会保存到第一台服务器上。

资源压缩，使用 protobuf 协议进行数据压缩

Google Protocol Buffer( 简称 Protobuf) 是 Google 公司内部的混合语言数据标准，目前已经正在使用的有超过 48,162 种报文格式定义和超过 12,183 个 .proto 文件。他们用于 RPC 系统和持续数据存储系统。Protocol Buffers 是一种轻便高效的结构化数据存储格式，可以用于结构化数据串行化，或者说序列化。它很适合做数据存储或 RPC 数据交换格式。可用于通讯协议、数据存储等领域的语言无关、平台无关、可扩展的序列化结构数据格式。Protobuf 由如 JSON 和 XML，不过它更小、更快、也更简单。你可以定义自己的数据结构，然后使用代码生成器生成的代码来读写这个数据结构。你甚至可以在无需重新部署程序的情况下更新数据结构。只需使用 Protobuf 对数据结构进行一次描述，即可利用各种不同语言或从各种不同数据流中对你的结构化数据轻松读写。

一句话描述：protobuf 是二进制协议, 通过给 json 设计了 schema 来提供更快的解析速度，主要是把比如{，"，key 等值舍弃，采用 tag|value 存值，传输效率极高，传输体积很小，在 tcp/rpc 里的使用很普及。

序列化耗时对比：

bytes 字节数对比：

Push 业务个协议对比：

结论：proto 的 Marshal 比 json 的 Marshal 快 2 倍，压缩后数据大小 proto 是 json 的 1/4，且数据越大优势越明显。最终频控数据压缩后节省 75%的 redis 资源。

三、总结

消息推送（Push）是移动端 App 产品运营的重要手段，成本低效益高。随着移动互联网的高速发展，手机应用的开发越来越成熟，应用的更新频率也随之提高，同时各应用推送的消息也是五花八门，能否及时和准确给用户推送他感兴趣的消息内容，提升推送信息的消费率是 Push 系统的核心价值。

“苹果之父”乔布斯曾说：“根据大众的需要去设计产品其实是非常难的。因为在很多情况下，人们并不知道自己想要什么，所以需要你去展示给他看。”我感觉这句话用在推送上也是合适的，对于明确自己想要什么样的消息内容的用户，推送内容可以投其所好（个性化推送）。对于不明确自己想要什么样的消息内容的用户，App 运营者在推送消息时需要考虑消息的可行性。不只是内容选择上需要谨慎，在时间，推送对象，推送方式上等都需深思熟虑（运营推送）。

推荐阅读：

｜百度爱番番数据分析体系的架构与实践

｜托管页前端异常监控与治理实战

｜基于etcd实现大规模服务治理应用实战

---------- END ----------

百度 Geek 说

百度官方技术公众号上线啦！

技术干货 · 行业资讯 · 线上沙龙 · 行业大会

招聘信息 · 内推信息 · 技术书籍 · 百度周边

欢迎各位同学关注