亿级规模的 Feed 流系统，如何轻松设计？

阿里妹导读：互联网进入移动互联网时代，最具代表性的产品就是各种信息流，像是朋友圈、微博、头条等。这些移动化联网时代的新产品在过去几年间借着智能手机的风高速成长。这些产品都是Feed流类型产品，由于Feed流一般是按照时间“从上往下流动”，非常适合在移动设备端浏览，最终这一类应用就脱颖而出，迅速抢占了上一代产品的市场空间。

简介

Feed流是Feed + 流，Feed的本意是饲料，Feed流的本意就是有人一直在往一个地方投递新鲜的饲料，如果需要饲料，只需要盯着投递点就可以了，这样就能源源不断获取到新鲜的饲料。 在信息学里面，Feed其实是一个信息单元，比如一条朋友圈状态、一条微博、一条咨询或一条短视频等，所以Feed流就是不停更新的信息单元，只要关注某些发布者就能获取到源源不断的新鲜信息，我们的用户也就可以在移动设备上逐条去浏览这些信息单元。

当前最流行的Feed流产品有微博、微信朋友圈、头条的资讯推荐、快手抖音的视频推荐等，还有一些变种，比如私信、通知等，这些系统都是Feed流系统，接下来我们会介绍如何设计一个Feed流系统架构。

Feed流系统特点

Feed流本质上是一个数据流，是将 “N个发布者的信息单元” 通过 “关注关系” 传送给 “M个接收者”。

Feed流系统是一个数据流系统，所以我们核心要看数据。从数据层面看，数据分为三类，分别是：

 

• 发布者的数据：发布者产生数据，然后数据需要按照发布者组织，需要根据发布者查到所有数据，比如微博的个人页面、朋友圈的个人相册等。
• 关注关系：系统中个体间的关系，微博中是关注，是单向流，朋友圈是好友，是双向流。不管是单向还是双向，当发布者发布一条信息时，该条信息的流动永远是单向的。
• 接收者的数据：从不同发布者那里获取到的数据，然后通过某种顺序（一般为时间）组织在一起，比如微博的首页、朋友圈首页等。这些数据具有时间热度属性，越新的数据越有价值，越新的数据就要排在最前面。

针对这三类数据，我们可以有如下定义：

• 存储库：存储发布者的数据，永久保存。
• 关注表：用户关系表，永久保存。
• 同步库：存储接收者的时间热度数据，只需要保留最近一段时间的数据即可。

设计Feed流系统时最核心的是确定清楚产品层面的定义，需要考虑的因素包括：

• 产品用户规模：用户规模在十万、千万、十亿级时，设计难度和侧重点会不同。
• 关注关系（单向、双写）：如果是双向，那么就不会有大V，否则会有大V存在。

上述是选择数据存储系统最核心的几个考虑点，除此之外，还有一些需要考虑的：

如何实现Meta和Feed内容搜索？

虽然Feed流系统本身可以不需要搜索，但是一个Feed流产品必须要有搜索，否则信息发现难度会加大，用户留存率会大幅下降。

Feed流的顺序是时间还是其他分数，比如个人的喜好程度？

• 双向关系时由于关系很紧密，一定是按时间排序，就算一个关系很紧密的人发了一条空消息或者低价值消息，那我们也会需要关注了解的。
• 单向关系时，那么可能就会存在大V，大V的粉丝数量理论极限就是整个系统的用户数，有一些产品会让所有用户都默认关注产品负责人，这种产品中，该负责人就是最大的大V，粉丝数就是用户规模。

接下来，我们看看整个Feed流系统如何设计。

Feed流系统设计

1. 产品定义

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

• 微博类
• 朋友圈类
• 抖音类
• 私信类

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

 

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

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

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

• 如果是单向，那么可能就会存在大V效