Feed系统设计分析（类似微博的用户动态分享问题）

Feed系统

最近在研究一个个人动态分享平台，对动态的推送方式有些疑惑，于是研究到了以下结果。

简介

在信息学里面，Feed其实是一个信息单元，比如一条朋友圈状态、一条微博、一条资讯或一条短视频等，所以Feed流就是不停更新的信息单元，只要关注某些发布者就能获取到源源不断的新鲜信息，我们的用户也就可以在移动设备上逐条去浏览这些信息单元。现在的微信、抖音、微博等这种类似个人动态的分享平台，都采用一种Feed流系统。类似私信、通知之类的系统也是Feed流系统的一种。

Feed流本质上是一个数据流，是将 “N个发布者的信息单元” 通过 “关注关系” 发送给 “M个接收者”。

它需要关注的是（用微博举例）：用户A在微博发布了一条动态，那么用户A的所有followers都需要接收到这条动态，我们要怎么将这条动态呈现到每个follower上？

系统分析

Feed流本质是数据流，那么从数据层面看，可以将产生的数据分为三类：

• 发布者的数据：

  发布者的数据按照发布者组织发布之后，需要推送给他的followers。比如微博的个人页面，朋友圈的个人相册。

  发布者的数据一般是需要永久保存的。

• 关注关系：

  系统中发布者和接收者之间的关系。在微博中，关注是单向流。微信中是好友，是双向流（加了好友相当于微博的互关）。但是，不管是单向流还是双向流，某条数据的流动是单向的。

  用户关系表，需要永久保存。

• 接收者的数据：

  从发布者获取数据，然后通过某种顺序组织到一起。像微博关注人的动态一般是按照时间顺序（如果没有关注是推荐的话，一般是按照喜好或者说点赞数播放量）。

  接收者的数据一般按照时间热度数据，只需要保留最近一段时间的数据。

Feed流数据的聚合

将存储的关注人的微博数据聚合成源源不断的信息流供用户访问，Feed系统一般有三种解决方案。

推模式

顾名思义，所谓推模式就是当用户发布一条动态之后，将这条动态自动发送（推）给他的followers的收件箱，因为有时候接收者并不在线，那么就需要一个收件箱来存储这个数据，这个存储的地方一般称之为同步库。

推模式的信息聚合简单，因为每一个用户只需要访问自己的收件箱就可以获取到关注人的动态。

问题在于：如果一个发布者拥有上千万个粉丝，那么就需要将这条数据推送千万次。这样会带来极大的写入量，给数据库或者服务器带来极大的压力，并且，这样的一条数据，会被存储多份，占用存储空间也大。如果该发布者还想要编辑或者修改动态，那么还需要在请求一遍所有粉丝的收件箱。因此，采用推模式，存储成本以及数据更新成本会非常高，需要大量的缓存和数据库以及队列机来更新。

拉模式

拉模式就是用户主动的遍历关注人列表，获取关注人列表中的所有动态更新，然后再按照时间聚合再一起，从用户的角度来看，请求的数据和计算量远大于推模式。但是是相当于用户主动的去获取关注人动态，不用发布者推送给每一个粉丝，并且如果要修改数据就需要关注自己的动态，修改即可，也不需要再请求粉丝的收件箱。

推拉结合

对比推模式和拉模式的优缺点，可以发现可以将两者结合起来，拥有粉丝数少的用户采用推模式，粉丝量大的用户采用拉模式。这样虽然合理，但是业务逻辑就比较复杂，难以确定哪些用户该使用推模式，哪些该采用拉模式，所以一般还是采用的拉模式。