19
经典系统设计图解笔记（二）：Feed 流系统
source link: https://www.raychase.net/6269
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
今天记录 Feed 流系统的设计学习笔记，Feed 流常见系统包括 Twitter、微博、Instagram 和抖音等等，它们的特点是，每个用户都是内容创作者，每个用户也都是内容消费者，每个用户看到的内容都是不同的，它取决于用户所关注的用户列表，再结合时间线（有时还包括优先级）将这些用户的最新 feed 聚合，并以流的方式展示出来。
- Feed 流系统中，有两种常见的模式，一种是 push，一种是 pull。基本上，对于用户的 “被关注用户”（粉丝）可能远大于 “关注用户” 的系统，比如 Twitter，pull model 是必选，push 是可选。对于明星用户，因为粉丝多，更适宜使用 pull 模型；反之则是 push。但是有利必有弊，如果二者结合使用，会增加系统的复杂性，这里按照二者结合的设计来叙述。
- 首先，用户和用户关联关系，存放在 User DB 里，和很多其它系统一样，它可以是一个关系数据库。
- 右侧的 Tweet Storage：用户和帖子（推文）的关联数据，数据量会比较大，可以选择 Redis 这样的 KV 数据库；而推文本身，也可以使用 KV 数据库，或者使用 MongoDB 这一类文档数据库，以适应弱结构化文本为主的数据，数据可以根据推文作者来 sharding，时间序索引化（基本上这所有和推文相关的数据，包括赞、转发、评论等等，全部都是和时间强相关的，因此一台存储节点上的这些数据可以全部是某一个时间段的，以提高基于时间段查询的效率）。但是，Twitter 和微博都使用了 MySQL 来存放这类数据，并且 Twitter 给 MySQL 做了相当的优化，这里面不只有技术原因，更多的还有历史原因。
- Media Storage，用于存放图像等媒体数据，这可以是一个 “单纯” 的分布式文件系统，比如 S3。
- 用户推文的时候，根据用户所应对的策略，如果需要 fan out 推文的 id 到粉丝的时间线中，就要把这个事件进 queue，由于它是异步模型，这一步可能会有不同程度的延迟。
- 在用户读取的时候，缓存是非常重要的，考虑到需要的容量巨大，为了增加命中率，减少冗余的缓存信息，可以使用集中式缓存集群。
- Aggregation Service 是用来从多个存储节点中为某个用户拉取数据（pull 模型），合并时间线，并返回的。为了提高效率，这里是多个并行拉取，再聚合的。这些数据可能是即时拉取的，也可能是已经，或者部分已经在之前的 Fan-out 流程中写入准备好了的。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK