设计一个feed流系统

什么是feed流系统

移动互联网时代，Feed流产品是非常常见的，如朋友圈、微博、抖音等，除此之外，很多App的都会有一个模块，要么叫动态，要么叫消息广场，这些也是Feed流产品。只要大拇指不停地往下划手机屏幕，就有一条条的信息不断涌现出来。就像给宠物喂食一样，只要它吃光了就要不断再往里加，故此得名Feed（饲养）。

feed流系统分类

Feed流的分类有很多种，但最常见的分类有两种：

分类	例子	阐述
Timeline	微信朋友圈	按发布的时间顺序排序，先发布的先看到，后发布的排列在最顶端。这也是一种最常见的形式。 这种一般假定用户Feed流中的Feed不多，但是每个Feed都很重要，都需要用户看到
Rank	抖音、今日头条	按某个非时间的因子排序，一般是按照用户的喜好度排序，用户最喜欢的排在最前面，次喜欢的排在后面。 这种一般假定用户可能看到的Feed非常多，而用户花费在这里的时间有限，那么就为用户选择出用户最想看的Top N结果

Feed流中的基本概念

• Feed：Feed流中的每一条状态或者消息都是Feed，比如微博中的一条微博就是一个Feed。
• Feed流：持续更新并呈现给用户内容的信息流。每个人微博主页都是一个Feed流。
• Timeline：Timeline其实是一种Feed流的类型，微博，朋友圈都是Timeline类型的Feed流，但是由于Timeline类型出现最早，使用最广泛，最为人熟知，有时候也用Timeline来表示Feed流。

两种Timeline

• 关注页Timeline（也叫home timeline）：展示多个用户的Feed消息的聚合页面（收集自当前用户所关注的其他用户的feed），比如朋友圈，微博的首页等。
• 个人页Timeline（也叫user timeline）：展示单独某个用户（自己或其他用户）发送过的Feed消息的页面，比如微博的个人页等。

比较常见的场景是，一个用户在home timeline里看到了某个很感兴趣的feed，然后进一步点开这个发布者的user timeline，查看这个发布者的其他feed内容。

实现

如果要设计一个Feed流系统，最关键的两个核心，一个是存储，一个是推送。

虽然我们只是以设计一个feed流系统来学习它的原理，但是也应该对标顶级的feed流系统来设计，通过考虑他们所面对的大数据量、高并发场景问题，来使我们能够进行更有价值的思考。

那么最顶级的feed流系统是什么样的呢？以facebook为例，2019年第四季度，facebook有16.6亿日活用户（daily active users），相当于21%的世界人口。25亿月活用户，相当于32%的世界人口。

ok，那我们的目标就是设计一个10亿日活的feed流系统，平均每个用户关注了500个其他用户。

流量预估

假设每个用户平均每天拉取10次feed流，那么每天就有100亿次拉取请求，QPS大约为116K。

存储预估

假设我们为每个用户用缓存存储500条feed以供快速浏览（这500条feed会实时更新，只有极少数人会每天刷超过500条feed），每条feed大约1KB，那就是每人500KB，总共500TB。

我们这里只讲理论，不讲具体的技术选型。具体落地时再考虑使用什么技术组件来满足流量和存储预估的容量。

存储

数据库模型

大致可以分为三种信息：

• Users：记录每个用户的个人信息（是否活跃用户、是否大V）
• Follows：记录不同用户之间的关系（用户A关注了用户B）
• FeedItems：记录每条Feed的内容

不同数据之间的关联：一个用户可以关注多个人，一个用户可以发布多条Feed。

数据和存储介质

不同的数据有不同的特性，各自需要单独的存储服务，各自使用合适的存储介质。

持久化存储

数据	特性	存储介质	数据服务简称	数据内容
Feed中的媒体内容，如图片和视频	占用空间大	对象存储	Object store	Video, image file
用户的个人信息，用户之间的关系	占用空间小，信息维度多，需结构化存储	SQL数据库（如MYSQL）	SQL database	user metadata
用户个人主页的feed数据	数据结构简单，KV结构，V为列表。需持久化存储。	NoSQL数据库	NoSQL data store	user timeline

feed流系统的所有数据都在持久化存储中保存，也是最原始的数据。但是还需要将一些数据放在缓存中，以应对高并发业务请求。

缓存

存储介质都是NoSQL缓存（如Redis）

数据	数据服务简称	数据内容
feed数据	feed items cache server	Feed_id:metadata
个人页Timeline	user timeline cache server	User_id:( list(feed_id), updated_at )
关注页timeline	home timeline cache server	Rank,sort,merge user_id: ( list(feed_id), updated_at )

推送

推拉之争

Pull Model（读扩散）

拉模型就是在查询时首先查询用户关注的所有创作者 uid，然后查询他们发布的所有文章，最后按照发布时间降序排列。用户每打开一次「关注页」系统就需要读取 N 个人的文章（N 为用户关注的作者数）, 因此拉模型也被称为读扩散。

• 优点：逻辑清晰直观，实现简单

• 缺点：每次阅读「关注页」都需要进行大量读取和一次重新排序操作，若用户关注的人数比较多一次拉取的耗时会长到难以接受的地步。

Push Model（写扩散）

推模型就是在创作者发布文章时就将新文章写入到粉丝的关注 Timeline，用户每次阅读只需要到自己的关注 Timeline 拉取就可以了。使用推模型方案创作者每次发布新文章系统就需要写入 M 条数据（M 为创作者的粉丝数），因此推模型也被称为写扩散。

• 优点：拉取操作简单、耗时短，用户体验良好。
• 缺点：粉丝量大的博主发布feed时，写入量巨大。

在线推，离线拉

推拉模型的对比

-	优点	缺点
推	读取快	1、逻辑复杂，占用大量存储空间 2、粉丝量大的博主发布feed时写入量巨大
拉	逻辑简单，不占用多余存储空间	读取慢，尤其是关注人数多的用户读取feed的速度非常慢

看起来推拉模型各有优缺点，但是在实际上，Feed 流是一个极度读写不平衡的场景，一般读写比例在10：1，甚至100：1以上。虽然推模型占用更多的存储空间，但是拉模型消耗的cpu资源也不逞多让。而且用户很难容忍打开页面时需要等待很长时间才能看到内容。因此无论是从资源消耗还是从用户体验出发，推模型都更有实用价值。

在确定要使用推模型的情况下，如何优化写扩散问题呢？实际上不一定需要把作者的新feed推给每个粉丝，因为粉丝中活跃用户数量是有限的，只需要推给活跃用户即可，而不活跃的用户则是等到他们回归的时候，再使用拉模型来构造feed流即可。

因此目前的feed流系统一般混合使用pull模型和push模型

• 非活跃用户的feed流，使用pull模型生成
• 活跃用户的feed流，使用push模型生成

下面的feed发布和feed读取也是以推拉混合模型为基础。

feed发布

用户（作者）创建一个新feed的写流程如下：

1. 客户端向负载均衡服务器发起一个http请求来创建一个新的feed
2. 负载均衡服务器选择一个负载较低的web服务器，传递http请求
3. web服务有限流功能
4. web服务把新feed推到消息队列中做异步处理，并直接返回即时响应
5. fanout（扩散）服务从消息队列中消费消息，把feed分发给多个服务器，来给该名作者的粉丝们的feed流里新增该feed
6. object store：存储新feed中的图片、视频等资源
7. NoSQL data store：把新feed存储在用户的个人主页timeline中（按时间顺序存储）
8. SQL database：存储用户信息，不过在写新feed的场景下应该不会涉及用户信息的修改。
9. feed items cache server：对于每一个超过一定粉丝量的用户，会存储他们的一部分最新的feed items内容（不包含图片、视频等媒介）在缓存中。
10. user timeline cache server：为每个用户缓存他们的个人主页timeline的feed id。
11. fanout服务请求feed生成服务
12. feed生成服务请求user info服务获取用户信息，包括：作者是否名人、作者的关注者是哪些用户、关注者们的活跃状态（user info服务把用户信息缓存在内存中）
13. ？
14. feed生成服务为关注者们的home timeline新增feed_id，缓存在home timeline cache server中，生成逻辑的详情写在下面
15. 对于非名人作者，feed生成服务用推模型以O(n)复杂度为每个关注者（不管是否活跃）的home timeline中新增一个新的feed_id（n为关注者数量）
16. 对于名人作者，feed生成服务使用推拉混合模型，只为活跃关注者生成feed流，不需要管非活跃的关注者，因为他们是使用拉模型来生成home timeline的。
17. 生成新feed后，更新每个相关的用户的home timeline，对其进行rank、sort和merge。

feed读取

用户拉取feed流的读流程如下：

1. 客户端查询DNS服务来做解析域名
2. 客户端查询CDN来看目标timeline的feed是否有被缓存
3. 客户端向负载均衡服务发起http请求
4. 负载均衡服务器选择一个负载较低的web服务器，传递http请求
5. web服务有限流功能
6. web服务向timeline服务请求timeline内容
7. timeline服务请求user info service获取用户信息，包括：当前用户是否活跃、当前用户关注了哪些人、当前用户是否关注了名人。
8. 假如用户请求的是home timeline，则timeline服务请求home timeline cache server来获取当前用户的home timline的feed_id列表
9. timeline服务请求feed items cache server，根据feed_id列表获取feed内容
10. 假如用户请求的是user timeline，则timeline服务请求user timeline cache server来获取目标用户的user timeline的feed_li列表，并且同样到feed items cache server，根据feed_id列表获取feed内容
11. 前面请求user info service获取用户信息时，如果cache miss了就请求SQL database来获取用户信息
12. timeline服务请求object store补充feed中的图片和视频数据
13. feed items cache server缓存不命中时，访问NoSQL data store获取feed内容
14. 非活跃用户请求home timeline时，不访问home timeline cache server，而是直接用拉模型来实时计算和获取feed流

参考文章

Designing a Social Media News Feed System

Design a News Feed System

如何打造千万级Feed流系统

从小白到架构师(4): Feed 流系统实战