别瞎搞了！微博、知乎就是这么设计Feed流系统的

# Feed流系统设计

上一节，我们提前思考了Feed流系统的几个关键点，接下来，在这一节，我们自顶向下来设计一个Feed流系统。

1. 产品定义

第一步，我们首先需要定义产品，我们要做的产品是哪一种类型，常见的类型有：

• 微博类

• 朋友圈类

• 抖音类

• 私信类

接着，再详细看一下这几类产品的异同：

上述对比中，只对比各类产品最核心、或者最根本特点，其他次要的不考虑。比如微博中互相关注后就是双向关注了，但是这个不是微博的立命之本，只是补充，无法撼动根本。

从上面表格可以看出来，主要分为两种区分：

• 关注关系是单向还是双向：

如果是单向，那么可能就会存在大V效应，同时时效性可以低一些，比如到分钟级别；

如果是双向，那就是好友，好友的数量有限，那么就不会有大V，因为每个人的精力有限，他不可能主动加几千万的好友，这时候因为关系更精密，时效性要求会更高，需要到秒级别。

• 排序是时间还是推荐：

用户对feed流最容易接受的就是时间，目前大部分都是时间。

但是有一些场景，是从全网数据里面根据用户的喜好给用户推荐和用户喜好度最匹配的内容，这个时候就需要用推荐了，这种情况一般也会省略掉关注了，相对于关注了全网所有用户，比如抖音、头条等。

确定了产品类型后，还需要继续确定的是系统设计目标：需要支持的最大用户数是多少？十万、百万、千万还是亿？

用户数很少的时候，就比较简单，这里我们主要考虑 亿级用户 的情况，因为如果系统能支持亿级，那么其他量级也能支持。为了支持亿级规模的用户，主要子系统选型时需要考虑水平扩展能力以及一些子系统的可用性和可靠性了，因为系统大了后，任何一个子系统的不稳定都很容易波及整个系统。

2. 存储

我们先来看看最重要的存储，不管是哪种同步模式，在存储上都是一样的，我们定义用户消息的存储为存储库。存储库主要满足三个需求：

• 可靠存储用户发送的消息，不能丢失。否则就找不到自己曾经发布到朋友圈状态了。

• 读取某个人发布过的所有消息，比如个人主页等。

• 数据永久保存。

所以，存储库最重要的特征就是两点：

• 数据可靠、不丢失。

• 由于数据要永久保存，数据会一直增长，所以要易于水平扩展。

综上，可以选为存储库的系统大概有两类：

• 对于可靠性，分布式NoSQL的可靠性要高于关系型数据库，这个可能有违很多人的认知。主要是关系型数据库发展很长时间了，且很成熟了，数据放在上面大家放心，而分布式NoSQL数据库发展晚，使用的并不多，