推模式和拉模式
所有设计题的回答思路都建议遵循：
- 需求引入和分析
- 数据库表设计
- 系统架构设计
- 接口设计：需要存在哪些 API，别人怎么调用
推模式
首先是推送的模式，又被称为写扩散。当我们进行写入或者说更新之后，会遍历所有关注我们的人，将更新推送给他们。
具体地，当我们发布一条新状态时，更新到自己的栏目中，即返回发布成功。同时在后台起一个异步任务，遍历所有关注的人，将更新推送给他们。
- 随便想想我们可以发现，每次更新都需要遍历所有关注的人，如果这个数量很大就会产生很大的压力。
- 如果有很多死粉的情况下，也会造成浪费。
- 由于异步操作的特性，可能存在有些用户获取到了，有些用户没有获取到的不一致情况。
因此对于粉丝体量很大的用户，推模式是不适用的。
推模式的优点是简单，不需要额外的服务器，缺点是效率低，如果有大量的更新，推送给每个人的时间会比较长。
拉模式
拉模式是一种关注者主动拉取的方式，又称读扩散。当用户需要更新时，他可以主动请求服务器，服务器将更新推送给他。
具体地，当我们需要发布一条新状态时，更新到自己的栏目中，并不会进一步完成推送。转换主体到关注者，尝试进行刷新自己的关注动态操作时，会遍历自己所有关注的人，查看他们所发布的内容，依照时间排序展示出来。
- 如果关注人群非常多，可能会产生很大的流量。
- 对于所有关注的人的更新内容需要进行聚合，接着可能出现排序、筛选等操作，会造成比较大的开销。
- 分页不便，毕竟涉及到对多个队列（抽象关注的人的动态）的按某种顺序（一般是时间）的读取。
- 如果有极其活跃的用户，可能会产生大量的流量。
因此对于关注人数较少的用户，拉模式是比较合适的。
拉模式的优点是可以节省服务器资源，可以根据用户的需要进行定制化的更新，缺点是需要用户主动进行操作，可能会造成信息不及时。
推拉结合
那么根据上面的分析，我们可以得出，对于粉丝数较少的用户，推模式是比较合适的，而对于粉丝数较多的用户，拉模式是比较合适的。
抽象出来就需要做两个判断：
- 粉丝量够不够大
- 活跃度如何
对于粉丝量较多的大 V，对于其活跃度很高的粉丝，采用主动的推模式，而活跃度低的则采用拉模式。对于粉丝量较小的普通用户，用主动的推模式也无伤大雅。
当然上面这两个判断的标准是模糊的，而不是绝对的，需要结合实际情况进行判断。
Feed 流的分页
对于分页的话，我们肯定就得框定范围。假设我们需要通过时间排序，一页要显示 10 条数据，那么对于第一页，我们只需要 ORDER BY 加 LIMIT 10 即可；那么对于第二页来说，我们得利用到第一页的部分，可以是用时间节点来卡，也可以通过主键 ID 来卡范围。以此来避免多次大量的无谓查询。