微博亿级Feed流系统设计

分享内容

1. Feed流业务场景
2. Feed流推拉模式
3. Feed流数据排序方式
4. Feed流数据结构和存储
5. 怎么解决大V发帖数据量大问题

简介

概念

Feed + 流（Feed 流将用户主动订阅的若干消息源组合在一起，形成内容聚合器，帮助用户持续的获取最新的订阅内容，Feed 流即持续更新并呈现给用户内容的信息流）

Feed：投喂

流：给用户呈现信息的形式

场景

① 社交互动类：微信、微博、Instagram、Facebook ...

② 新闻资讯类：今日头条、腾讯新闻 ...

③ 视频直播类：抖音、快手 ...

主要模式

1. 推模式：用户发帖，对所有粉丝推送该消息（不适合大 V）
2. 拉模式：主动拉取用户所有关注这的最近动态列表（不适合关注了很多用户的用户）
3. 推拉模式结合

排序方式

1. TimeLine 排序：按照发布时间顺序排序，先发布的先看到，后发布的排列在最顶端，类似于微信朋友圈（产品如果选择 Timeline 类型，那么就是认为 Feed 流中的 Feed 不多，但是每个 Feed 都很重要，都需要用户看到）
2. Rank 排序：按照非时间的因子排序，一般按照用户的喜爱好度排序（这种一般假定用户可能看到的 Feed 非常多，而用户花费在这里的时间有限，那么就为用户选择出用户最想看的 Top N 结果，场景的应用场景有微博、头条新闻推荐类、商品、视频推荐等）
3. 智能排序：基于趋势 trending、热门 hot、编辑推荐 PGC 等因素综合考虑

Feed流系统设计

业务特点

海量数据、高访问量、非均匀

1. 海量用户数据：亿级别的用户数量，每个用户千级别的帖子数量，平均千级别的 follower/attention 数量
2. 高访问量：每秒十万量级的访问页面，每秒万量级别的帖子发布
3. 用户分布非均匀：部分用户的帖子数量 / follower 数量，相关页面访问数量会超出其他用户几十个数量级
4. 时间分布非均匀：某个用户在某个时间点成为热点用户，其 follower 可能徒增数个量级

核心问题 1：“关注模型” 的存储

最简单的是基于 DB 的存储，只需要两张表 relation_tab \ user_info_tab

user_info_tab 用户信息表：自增 id、用户账号 user_id、用户信息（头像、名称、注册时间、大 v 认证、手机号等）

relation_tab 关系表：自增 id、关注者 id、被关注者 id

==> 所以，只需要查询 2 张表就可以查询出关注、粉丝、用户信息

// 查询所有“关注者”关注的人
select count(*) from relation_tab where 关注者id='xx'
// 查询“被关注者”所有的粉丝
select count(*) from relation_tab where 被关注者id='xx'
// 根据用户账号，查询user_info
select * from user_info_tab where user_id='xx'

随着用户的增多，relation_tab \ user_info_tab 表的行数增多。千万、亿级用户，每个用户相关关系百级，那么就需要水平拆分。

user_info_tab 用户信息表拆分规则：水平拆分

1. 上亿的数据量，拆分成 10~20 张表，每张表保存约 500~1000 万个用户：表名 user_info{idx}tab

照 user_id，hash 取模，得到 idx，数据存放在 user_info{idx}tab

relation_tab 关系表拆分规则：垂直拆分 + 水平拆分

根据 2 种业务场景进行水平拆分

1. 根据 follower 进行水平拆分：查询 follower 关注的列表很简单，但是查询 follower 的粉丝很难
2. 根据 attention 进行水平拆分：查询 attention 的粉丝列表很简单，但是查询 attention 关注的人很难

针对上述问题，进行垂直拆分，

1. 分为 follower 表和 attention 表，分别记录了某个用户的关注者和被关注者。表字段

• follower 表：自增 id、user_id、follower_id
• attention表：自增 id、user_id、attention_id