简介
Feed流是Feed + 流，Feed的本意是饲料，Feed流的本意就是有人一直在往一个地方投递新鲜的饲料，如果需要饲料，只需要盯着投递点就可以了，这样就能源源不断获取到新鲜的饲料。 在信息学里面，Feed其实是一个信息单元，比如一条朋友圈状态、一条微博、一条咨询或一条短视频等，所以Feed流就是不停更新的信息单元，只要关注某些发布者就能获取到源源不断的新鲜信息，我们的用户也就可以在移动设备上逐条去浏览这些信息单元。
当前最流行的Feed流产品有微博、微信朋友圈、头条的资讯推荐、快手抖音的视频推荐等，还有一些变种，比如私信、通知等，这些系统都是Feed流系统。
本文以新浪微博介绍3种feed设计的方法：
场景：用户A，有粉丝B、C、D，用户A发一条微博
-
拉
拉的方式使用两张表即可实现
微博表（微博ID，微博内容，发布人）
关注表（博主ID）
a）A发微博，将微博写入微博表；
b）客户端通过查询微博接口，在关注表查询B/C/D关注的博主，再去微博表查询A发布的微博，将结果按时间排序，分页返回。
如下图：
图片.png
拉的方式缺点是查询慢
-
推
推的方式需要三张表
微博表（微博ID，微博内容，发布人）
粉丝表（粉丝ID）
feed表（微博ID，微博内容，接收人）
a）A发布微博，写入微博表
b）后端查询A的粉丝表，将微博内容和接收人写入feed表
c）客户端查询关注表，再查询feed表获取关注的内容
如下图:
图片.png
推的方式缺点是数据量大，A有n个粉丝，就需要往feed表中写入n条记录，没发布一次微博，就产生n+1条数据。当n为几百万、几千万时，数据库的压力就很大。
- 推+拉
推+拉的方式需要四张表
微博表（微博ID，微博内容，发布人）
粉丝表（粉丝ID，是否活跃）
关注表（博主ID）
feed表（微博ID，微博内容，接收人）
a）A发布微博，写入微博表
b）后端查询A的粉丝表，查找活跃的粉丝，将微博内容和接收人写入feed表
c）活跃用户查询关注表，再查询feed表获取关注的内容
d）非活跃用户查询关注表，再查询微博表获取关注的内容
e）维护粉丝活跃度
如下图：
图片.png
相比于推，feed表中的数据量大幅减少。
