万字21图！手把手教你设计一个超级牛逼的 Feed 流系统

8. 排序

目前的Feed流系统中的排序方式有两种，一种是时间，一种是分数。

我们常用的微博、朋友圈、私信这些都是时间线类型的，因为这些产品定义中，需要我们主动关注某些人后才会看到这些人发表的内容，这个时候，最重要的是实时性，而不是发布质量，就算关注人发布了一条垃圾信息，我们也会被动看到。这种类型的产品适用于按照时间线排序。这一篇我们介绍的架构都是基于时间类型的。

另外一种是不需要关注任何人，我们能看到的都是系统希望我们看到的，系统在后台会分析我们的每个人的爱好，然后给每个人推送差异化的、各自喜欢的内容，这一种的架构和基于时间的完全不一样，我们在后续的推荐类型中专门介绍。

9. 删除Feed内容

在Feed流应用中有一个问题，就是如果用户删除了之前发表的内容，系统该如何处理？因为系统里面有写扩散，那么删除的时候是不是也要写扩散一遍？这样的话，删除就不及时了，很难应对法律法规要求的快速删除。

针对这个问题，我们在之前设计的时候，同步表中只有消息ID，没有消息内容，在用户读取的时候需要到存储库中去读消息内容，那么我们可以直接删除存储库中的这一条消息，这样用户读取的时候使用消息ID是读不到数据的，也就相当于删除的内容，而且删除速度会很快。除了直接删除外，另外一种办法是逻辑删除，对于删除的feed内容，只做标记，当查询到带有标记的数据时就认为删除了。

10. 更新Feed内容

更新和删除Feed处理逻辑一样，如果使用了支持多版本的存储系统，比如Tablestore，那么也可以支持编辑版本，和现在的微博一样。

11. 总结

上面介绍了不同子功能的特点和系统要求，能满足需求的系统主要有两类，一类是阿里云的Tablestore单系统，一类是开源组件组成的组合系统。

• 开源组件组成的组合系统：包括MySQL、Redis、HBase等，这些系统单个都不能解决Feed流系统中遇到的问题，需要组合在一起，各司其职才能完成一个Feed流系统，适用于热衷开源系统，人多且喜欢运维操作的团队。

• Tablestore单系统：只使用Tablestore单个系统就能解决上述的所有问题，这时候肯定有人要问？你是不是在吹牛？这里不是吹牛，Tablestore在三年前就已经开始重视Feed流类型业务，之前也发表过多篇文章介绍，功能上也在专门为Feed流系统特别定制设计，所以到今天，只使用Tablestore一款产品，是可以满足上述需求的。选择Tablestore做Feed流系统的用户具有以下一些特征：

  产品设计目标规模大，千万级或亿级。

  不喜欢运维，喜欢专注于开发。

  高效率团队，希望尽快将产品实现落地。

  希望一劳永逸，未来系统随着用户规模增长可以自动扩容。

  希望能按量付费，用户少的时候费用低，等用户增长起来后费用在跟随用户数增长。

  如果具有上述四个特征的任何一个，那么都是适合于用Tablestore。

架构实践

上面我们介绍了Feed流系统的设计理论，具体到不同的类型中，会有不同的侧重点，下面会逐一介绍。

朋友圈

朋友圈是一种典型的Feed流系统，关系是双写关系，关系有上限，排序按照时间，如果有个人持续产生垃圾内容，那就只能屏蔽掉TA，这一种类型就是典型的写扩散模型。

我们接下来会在文章《朋友圈类系统架构设计》中详细介绍朋友圈类型Feed流系统的设计。

微博

微博也是一种非常典型的Feed流系统，但不同于朋友圈，关系是单向的，那么也就会产生大V，这个时候就需要读写扩散模式，用读扩散解决大V问题。同时，微博也是主动关注类型的产品，所以排序也只能是时间，如果按照推荐排序，那么效果就会比较差。

接下里会在文章《微博类系统架构设计》中详细介绍微博类型Feed流系统的设计。

头条

头条是最近几年快速崛起的一款应用，在原有微博的Feed流系统上产生了进化，用户不需要主动关注其他人，只要初始浏览一些内容后，系统就会自动判断出你的喜好，然后后面再根据你的喜好给你推荐你可能会喜好的内容，训练时间长了后，推送的内容都会是你最喜欢看的。

私信

私信也算是一种简单的Feed流系统，或者也可以认为是一种变相的IM，都是单对单的，没有群。我们后面也会有一篇文章《私信类系统架构设计》中做详细介绍。

总结

上面我们介绍了Feed流系统的整体框架，主要是产品定义、同步、存储、元数据、评论、赞、排序和搜索等内容，由于篇幅有限，每一章节都介绍的比较简单。读者如果对某一部分看完后仍然有疑问，可以继续再文后提问，我会继续去完善这篇文章，希望未来读者看完这篇文章后，就可以轻轻松松设计出一个亿级规模的Feed流系统。

另外，我们也欢迎有兴趣的读者一起来完成这个系列，帮忙实现朋友圈、微博、头条或者私信类型的文章，有任何问题都欢迎来讨论。