分布式应用系统设计.Feed 流系统(学习笔记）

什么是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 流系统 – 四火的唠叨