Feed流系统

Feed 流产品在我们手机APP中几乎无处不在，比如微信朋友圈、新浪微博、今日头条等。

只要大拇指不停地往下划手机屏幕，就有一条条的信息不断涌现出来。

• 就像给宠物喂食一样，只要它吃光了就要不断再往里加，故此得名Feed（饲养）。

Feed 流产品一般有两种形态：

• 一种是基于算法推荐
• 另一种是基于关注关系并按时间排列。

关注页这种按时间排序的 Feed 流也被为 Timeline。

• 关注页 存放自己发送过的 Feed 的页面，比如微博的个人页。

拉模型

查询时首先查询用户关注的所有创作者ID，然后查询他们发布的所有文章。

• 最后按照发布时间降序排列。

使用拉模型方案用户每打开一次 关注页 系统就需要读取 N 个人的文章（N 为用户关注的作者数）。

• 因此拉模型也被称为读扩散。

拉模型不需要存储额外的数据，而且实现比较简单。

拉模型的问题，每次阅读 关注页 都需要进行大量读取和一次重新排序操作。

• 若用户关注的人数比较多一次拉取的耗时会长到难以接受的地步。

推模型

在创作者发布文章时就应该将新文章写入到粉丝的关注 Timeline。

• 用户每次阅读只需要到自己的关注 Timeline。

使用推模型方案创作者每次发布新文章系统就需要写入 M 条数据（M 为创作者的粉丝数）。

• 因此推模型也被称为写扩散。

推模型的好处在于拉取操作简单高效。

但是，在每篇文章要写入 M 条数据，粉丝数有几十万甚至上百万的头部创作者每次发布文章时都有巨大的写入量。

通常为了发布者的体验文章成功写入就向前端返回成功。

• 然后通过消息队列异步地向粉丝的关注 Timeline 推送文章。

对比一下推拉模型：

推拉结合

先从关注列表中读取到自己的粉丝列表，以及判断自己是否是大V。

将自己的Feed消息写入个人页Timeline。

• 如果是大V，写入流程到此就结束了。

如果是普通用户，还需要将自己的Feed消息写给自己的粉丝。

• 如果有100个粉丝，那么就要写给100个用户。