什么是Feed 流系统
今天记录 Feed 流系统的设计学习笔记,Feed 流常见系统包括 Twitter、微博、Instagram 和抖音等等,它们的特点是,每个用户都是内容创作者,每个用户也都是内容消费者,每个用户看到的内容都是不同的,它取决于用户所关注的用户列表,再结合时间线(有时还包括优先级)将这些用户的最新 feed 聚合,并以流的方式展示出来。
用户周围用户分为
1. 我关注的(我想看的)
2. 关注我的(看我写的)
用户获取信息模式
push:服务器推给用户的模式,服务器给我每个用户预留一定空间,我关注的博主发博文后,服务器就会将博文给我复制一份(多少个关注人就复制多少份)
pull:用户从服务器拉的模式,服务器不给每个人在服务器预留空间,我上线后刷新,就去关注的博主挨个拉取,并按照时间线聚合,形成流给我输出
经典场景:一个大V粉丝众多
1. 如果采用push模式,都复制一份,则会占用很多空间
2. 博文可以采用ID,将ID推送给粉丝,这就需要在刷新页面的时候再读取一次博文
3. 读取博文可以进行缓存,而不是IO
4. 另一种思路是:减少推送的数量,比如只推送给活跃的粉丝
5. 换种思路,如果用pull(拉)模式,就可能一个大V的八卦会瞬间大流量的读,服务器可能扛不住
6. 缓存博文,并进行流控,防止大流量冲垮服务
用户信息和关系存储
1. 用户信息:用关系型数据库MySQL
2. 用户关系:用图数据库GraphDB,也可以用MySQL
博文存储
1. 可以使用 KV 数据库
2. 也可以使用 MongoDB 这一类文档数据库,以适应弱结构化文本为主的数据
3. 使用MySQL存储时需要考虑性能问题
用户和博文的关联数据存储
1. 数据量会比较大,可以选择 Redis 这样的 KV 数据库
2. Sharding 维度问题:博文数据量巨大,需要集群存储,那按照什么维度进行分片呢
3. 常用的有:按照时间维度;按照博文ID;按照用户ID Hash
4. 时间维度:新老数据访问不均,新数据访问的多
5. 博文维度:一个人的博文会存储在多个机器,需要挨个查询聚合
6. 用户维护:用户活跃程度不同
图片,视频和文件存储
OBS,S3等文件系统
发文过程
1. 记录博文
2. 如果是push模式,则进行推送。用户的聚合服务将博文按照时间线聚合起来
3. 如果是pull模式,则不进行处理
读取博文
1. 如果是push模式则读取自己,已聚合起来的消息
2. 如果是pull模式,则需要读取并聚合
学习博文:
常见分布式应用系统设计图解(二):Feed 流系统 – 四火的唠叨