简述Feed流系统设计

简述Feed流系统设计

本文侧重于概念普及，包括如下四部分：

一、什么是Feed流；

二、Feed流系统的技术特点；

三、Feed流系统的架构设计；

四、Feed流系统的广告统计。

|0x00 什么是Feed流

单独说起“ Feed流 ”，绝大多数人都会很陌生，但如果说起微信朋友圈、微博、抖音，那么大家顺便感觉亲切多了。简单理解Feed流，是一种呈现推荐内容给用户，并能够持续更细的方式。

早期的Feed源于新闻界的RSS系统，用户可以选择订阅多个资讯源，由系统整合到一起，按时间顺序推送给用户。Facebook崛起之后，将这种模式进行了扩展，升级成了全新的News Feed，也就是订阅源不再是某个具体的新闻媒体，而是来自于生产内容的人，而内容也不再局限于用时间进行排序，而是可以推荐一些热门的内容或者是广告。差不多十年前，随着移动互联网的普及，微博、微信、头条、快手等基于内容推荐的公司兴起，Feed流这种按照 时间 + 推荐 进行流动展示内容的方式，非常的适合于手机等移动端，最终在与PC端的较量中脱颖而出，将新闻媒体彻底打入了旧时代的序列。

Feed流是 Feed + 流 ，Feed的本意是饲料，Feed流的本意就是有人一直在往一个地方投递新鲜的饲料，如果需要饲料，只需要盯着投递点就可以了，这样就能源源不断获取到新鲜的饲料。

Feed流有这么三个显著的特点：

• 消息可靠性要求高 ：由于关注、取关等操作的存在，系统中的用户关系是在一直变化中的不稳定状态，但不论关系如何变化，用户能看到的信息是不能出现错误的，以微信朋友圈为例：如果我删除好友后，还能继续看到他/她的朋友圈，那么这个问题可能就不仅仅是简单的技术问题了……




• 多账号的互动模式 ：推荐的数据不仅可以来自于关注的大V，或者是好友，也可以基于热门的内容，或者是系统的推荐；




• 对广告主更友好 ：广告是基于推荐的方式展示给用户，相对于搜索等广告，不仅展示形式更加丰富，用户的触达链路也更短，广告转化率提升明显。

|0x01 Feed流系统的技术特点

首先普及一些基础的概念：

• Feed流 ：基于Feed+流的概念组合，Feed可以简单理解为 消息 的意思，比如一条朋友圈、或者是一条微博，流是持续展示的意思，例如微博的无限下拉更新，总要有内容展示给用户；




• Timeline ：Feed流的一种类型，意为“ 时间线 ”，按发布的时间顺序排序，先发布的先看到，后发布的排列在最顶端，最早由Twitter普及；




• Rank ： 推荐系统使用的排序权重 ，一般讲用户可能喜欢这条消息的权重越高，Rank就越靠前，也可以理解为用户最喜欢内容的TopN合集，对于CTR的提升帮助明显；




• 收件箱 ：用来存储消费最终接收到的一个 Feed流列表 。

Feed流的元数据：由于Feed通常需要存储和计算海量的信息，因此收件箱通常不会存储全部的Feed信息，而是会把关键信息提取出来，以降低存储和计算的数据量， 这些被提取出来的关键信息，就是“元数据” 。例如一个视频，我们只会存储它的ID、类别、格式、长度、大小、播放地址等信息；一条新闻，只会存储它的ID、类别、标题、来源、访问地址等信息。

Feed流【生产】的过程：

• 首先，Feed流系统的用户或者机构 产生内容 ，系统将内容收录到内容库中；




• 其次，系统根据已有的 业务规则 ，将新增的内容，提交到 分发中心 ；




• 最后，分发中心根据要投递的名单列表，向对应的账号收件箱中，插入Feed的 索引信息 。

Feed流【获取】的过程：

• 从账号收件箱中获取 增量Feed信息 ；




• 根据时间戳、好友关系、自定义等条件，过滤要显示的数据，并 进行排序 ；




• 用户 消费 收件箱里的信息内容。

Feed流实现的三种方式：

• 拉模式 ：发布者的内容仅仅写入自己的发件箱里，当用户访问自己的收件箱时，首先遍历这个用户的关系列表，然后再从关系列表的发件箱里读取数据，最后按照规则进行过滤和排序，这种方式的 优点是 写数据快，但读数据就要慢很多 ，适合于大V模式；




• 推模式 ：发布者的内容不仅写入自己的发件箱里，通过批处理任务，还需要写到对应关系人的收件箱里，当用户访问自己的收件箱时，直接从自己的收件箱里读取数据，最后按照规则进行过滤和排序，这种方式的 优点是写数据很慢，但读数据就要快很多 ，适合于关系社交；




• 推拉结合模式 ：大V与普通用户分开维护。

|0x02 Feed流系统的架构设计

用阿里云开发者社区的话讲：Feed流本质上是一个数据流，是 将 “N个发布者的信息单元” 通过 “关注关系” 传送给 “M个接收者” 。

这层抽象的概念，总结了我们设计Feed流的两个核心：即 存储系统、推送系统 。

存储系统目的有两个， 一个是数据不丢失，一个是数据可以永久保存 。早期微的系统使用Redis内存数据库来提高产品的响应速度，但由于成本增长非常快，因此总要有一些其他的方案来进行替代。Feed流系统虽然数据量级很大、对数据的可靠性要求很高，但它有一个很显著的特点，就是“ 关系极其简单 ”，这对于我们的技术选型提供了实现的思路。针对这种情况，我们可以设计如下的三种解决方案：

1. Mysql分库分表方案 ，非常稳定可靠，如果数据量级不大，采用这种方案能够有效的降低开发时间及运维时间，由于发展历史很长，技术也很成熟；




2. NoSQL方案 ，典型的代表是 HBase ，key-value型的数据库天然的适合二元关系场景，能够存储海量的数据，由于发展历史也很长了，因此可靠性是有保障的，但HBase的问题在于需要一定的运维成本；




3. 商业方案 ， TableStore (表格存储)是阿里云2013年推出的一款分布式数据库，存储账号关系是一个比较好的选择。

推送系统目的是解决消息的时效性。Feed流系统有一个很显著的特点，即 读写是非常不平衡的 ，绝大多数情况下， 用户都在“读”，而内容只有少量的人来“写” 。因此，推送系统会面临如下几个方面的压力：

• TPS/QPS是千万级的；




• 读写操作对于延迟非常敏感；




• 消息严格意义上是不能丢失的；




• 对于主键自增有很强烈的诉求。

因此，推送系统最好是一个 性能不错 ，又能 主键自增 的系统，而 内存数据库Redis 就能比较好的满足这些要求。但Redis由于属于内存数据库，成本非常好，而且Redis单机的特性，会带来不小的运维复杂性。对于工程师而言，思考的就是如何尽可能的少向Redis中写数据，比如只计算ID的数据，然后去存储系统获取Feed的信息。

|0xFF Feed流系统的广告统计

Feed流系统的广告主要设计为四个部分： 流量端（内容生产）、投放端（广告主投放设置）、检索端（广告策略设定）、展示端（广告数据的展示） 。

一次正常的广告投放流程，是广告主首先设定好对应的广告素材，当流量端有资源请求时，检索端拉取广告素材，进行策略的匹配，下发给展示端，完成广告的展示、点击、计费与转化过程。

因此我们统计Feed的广告，考虑的是如下几个指标：

• 请求量 ：检索端请求投放端的次数；




• 下发量 ：检索端下发给展示端的次数；




• 展示量 ：广告展示了多少次；




• 点击量 ：广告点击了多少次；




• 计费量 ：本次广告收了广告主多少钱。

自上向下就是一个完整的转化漏斗模型。

通常情况下，Feed流广告有两大类： 品牌广告和效果广告 。品牌广告的目的是为了提高品牌曝光度，让更多人记住。效果广告的目的是为了通过广告刺激用户行为，提升转化率。这两类由于展示方式的不同，在数据的埋点上会有一定的差异，统计规则就不再赘述。

最后，聊一下广告数据的事情， 从用户体验的角度来说，没有广告才是最佳的体验，但是从商业变现角度来说，越多的广告带来的收益越高，才有更多的钱去做更多的事情 。这两者之间看似的相互矛盾关系，是为了产品可以走的更远，双方都有有所退步， 数据起到的作用，就是尽可能的让广告内容匹配用户的预期，在尽可能保证用户体验的同时又可以实现一定程度的商业变现 。