导读：短视频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 说
百度官网技术公众号上线啦！
技术干货 · 行业资讯 · 线上沙龙 · 行业大会
招聘信息 · 内推信息 · 技术书籍 · 百度周边
欢送各位同学关注