导读：短视频 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 说

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

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

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

欢送各位同学关注