Feed 流怎么做？

相关概念

什么是 feed 流

• Feed：Feed 流中的每一条状态或者消息都是 Feed，比如微博中的一条微博就是一个 Feed。
• Feed流：持续更新并呈现给用户内容的信息流。每个人的朋友圈，微博关注页等等都是一个 Feed 流。

feed 流分类

Feed 流常见的分类有两种：

• Timeline：按发布的时间顺序排序，产品如果选择 Timeline 类型，那么就是认为 Feed 流中的 Feed 不多，但是每个 Feed 都很重要，都需要用户看到。类似于微信朋友圈，微博等。
• Rank：按某个非时间的因子排序，一般是按照用户的喜好度排序，一般用于新闻推荐类、商品推荐等。

设计

设计一个 Feed 流系统，两个关键步骤，一个是 Feed 流的 初始化，一个是 推送。关于 Feed 流的存储其实也是一个核心的点，但是笔主持久化使用的还是 MySQL，后续可以考虑优化。

Feed 流初始化

Feed 流【关注页 Feed 流】的初始化指的是，当用户的 Feed 流还不存在的时候，为该用户创建一个属于他自己的关注页 Feed 流，具体怎么做呢？其实很简单，遍历一遍关注列表，取出所有关注用户的 feed，将 feedId 存放到 redis 的 sortSet 中即可。这里面有几个关键点：

• 初始化数据：初始化的数据需要从数据库中加载出来。
• key 值：sortSet 的 key 值需要使用当前用户的 id 做标识。
• score 值：如果是 Timeline 类型，直接取 feed 创建的时间戳即可。如果是 rank 类型，则把你的业务对应的权重值设进去。

发布/删除 Feed 流

经过上面的初始化，已经把 feed 流放在了 redis 缓存中了。接下来就是需要更新 feed 流了，在下面四种情况需要进行更新：

1. 关注的用户发布新的 feed：
2. 关注的用户删除 feed。
3. 用户新增关注。
4. 用户取消关注。

上面四步具体怎么操作，会在下面的实现步骤中详细描述，在这里先我们重点讨论一下第一、二种情况。因为在处理 大 V 【千万级别粉丝】的时候，我们是需要对 大 V 的所有粉丝的 feed 流进行处理的，这时候涉及到的量就会非常巨大，需要多加斟酌。关于推送，一般有两种 推/拉。

• 推：A 用户发布新的动态时，要往 A 用户所有的粉丝 feed 流中推。
• 拉：A 用户发布新的动态时，先不进行推送，而是等 粉丝进来的时候，才主动到 A 用户的个人页 TimeLine 拉取最新的 feed，然后进行一个 merge。如果关注了多个大 V，可以并发的向多个大 V 个人页 TimeLine 中拉取。

推拉结合模式

当用户发布一条新的 Feed 时，处理流程如下：

1. 先从关注列表中读取到自己的粉丝列表，以及判断自己是否是大 V。
2. 将自己的 Feed 消息写入个人页 Timeline。如果是大 V，写入流程到此就结束了。
3. 如果是普通用户，还需要将自己的 Feed 消息写给自己的粉丝，如果有 100 个粉丝，那么就要写给 100 个用户。

当刷新自己的 Feed 流的时候，处理流程如下：

1. 先去读取自己关注的大 V 列表
2. 去读取自己的 Feed 流。
3. 如果有关注的大 V，则再次并发读取每一个大 V 的个人页 Timeline，如果关注了 10 个大 V，那么则需要 10 次访问。
4. 合并 2 和 3 步的结果，然后按时间排序，返回给用户。

至此，使用推拉结合方式的发布，读取 Feed 流的流程都结束了。

推模式

如果只是用推模式了，则会变的比较简单：

• 发布 Feed：
  • 不用区分是否大 V，所有用户的流程都一样，都是三步。
• 读取 Feed 流：
  • 不需要第一步，也不需要第三步，只需要第二步即可，将之前的 2 + N(N 是关注的大 V 个数) 次网络开销减少为 1 次网络开销。读取延时大幅降级。

两种模式总结：

推拉结合存在一个弊端，就是刷新自己的 Feed 流时，大 V 的个人页 Timeline 的读压力会很大。

如何解决：

1. 不使用大 V/普通用户的优化方式，使用对活跃粉丝采用推模式，非活跃粉丝采用拉模式。
2. 完全使用推模式就可以彻底解决这个问题，但是会带来存储量增大，大 V Feed 发送总时间增大，从发给第一个粉丝到发给最后一个粉丝可能要几分钟时间。