Timeline Feed系统设计

背景介绍

Feed 是一种承载信息的单元，feed系统就是信息分发系统。信息分发是所有互联网应用的基本功能，也是其立身根本，淘宝/头条/抖音/微博 等等APP都必须具有首页功能，首页通常用来展示Feed列表，信息分发承载着用户留存和商业化的重要目标，从技术上对延迟和可用性拥有极高的要求，每一次事故都会上热搜，了解Feed系统的设计对于后端工程师的成长是极为重要的。​

Feed 系统通常有两个要素，召回和排序，召回决定有哪些feed应该分发给哪些用户，而由于手机屏幕只有手掌大小，信息的展示位不足，所以必须要区分展示信息的优先级，因此就要有排序规则。根据这两点不同，通常可以分为  Timeline Feed 和 Top K Feed。​

 Timeline Feed 指的是根据用户与用户之间的关注关系来召回Feed，然后基于发布时间排序的简单信息流系统。​

Top K Feed 指的是根据某些召回策略，召回feed，然后基于推荐模型排序的复杂推荐系统。​

本文讨论  Timeline Feed 系统的设计，本文的目标不是一个面向面试的Timeline Feed系统设计，而是一个程序员在实际工作中的落地思考。系统设计是一个开放性话题，如果有遗漏错误之处，可直接评论，技术需要交流。​

为了避免侵权，我们以小视频的feed场景为参考，假设一款小视频微博: video_feed app。​

设计目标​
a.
用户发布一篇Feed(itme)(视频/文章/推文/微博/朋友圈等)​
b.
用户关注其他用户/取消关注的用户​
c.
用户查看订阅频道，可以看到关注的用户发布的Feed，以发布时间排序​
d.
用户可以点击某个feed，进入到当前feed的详情页面。​
e.
用户可以点击某个用户头像，进入到该用户主页面，展示他曾经发布的Feed​
f.
用户可以点赞，评论，转发一篇Feed，用户的feed上也会展示标题/封面/点赞/评论/浏览数信息​
g.
用户可以看到自己的收藏/点赞/浏览记录 列表，并设置是否公开的权限​
h.
合规安全性，不能放出非法内容，需要有审核机制。​

评估标准

以500Mli DAU 来进行估算

黄金指标

接口	延迟p99上限	吞吐量平均值	吞吐量峰值	可用性
Feed 列表接口	<= 200ms	60K QPS	90K QPS	5个9
用户发布小视频接口	<= 500ms	6K QPS	12K QPS	5个9
用户访问视频详情页&个人主页	<= 200ms	2k QPS	3K QPS	4个9
用户关注/点赞/转发	<= 50ms	6K QPS	12K QPS	4个9
用户发布评论接口	<= 300ms	2k QPS	5k QPS	3个9
用户读取评论列表	<= 200ms	10K QPS	20K QPS	3个9
用户访问收藏/点赞/浏览记录列表	<= 200ms	1K QPS	1.5KQPS	3个9

存储容量

假设一篇发feed视频 2MB ，则一天存储增量 2MB* 6K * 24 * 60 * 60 约等于 1000TB 存储。​

网络带宽

网络请求的带宽可以忽略不计，但是视频CDN的带宽是巨大的，这里近似等于视频的大小2M，​

用户一刷10条Feed，小视频形式每刷都会点击，所以CDN消耗近似等于视频分发的量级​
10条 * 60K * 2M * 24h * 60min * 60s 约等于100PB。​

负载特性

Feed系统是一个典型的读多写少负载场景，通常为100:1, 一个用户发feed，有100个用户会阅读此feed。​

方案设计

初始方案

服务拆分，通过名词抽象为服务边界，接口为动词。​
a.
User server， 存储用户信息，提供CURD用户维度属性的能力。​
b.
Item server，  存储原始内容，提供发布和查询内容的能力。​
c.
Feed server， 存储feed信息，提供获取信息流列表的能力，个人主页/浏览记录/收藏列表等。​
d.
Relation server，存储用户与用户的关系，关注/朋友等，获取粉丝列表，关注列表等。​
e.
Comment server，存储评论数据，拉取评论列表，发布评论，获取评论数。​
f.
API server， 用来聚合用户请求，进行逻辑控制。​

接口交互

用户注册

API server调用user server鉴权/注册用户信息写入DB即可。

用户关注

用户直接写接口即可。

Timeline Feed系统设计​

Timeline Feed系统设计