title: Notes of System Design No.04 —Design a Twitter
description: ’ Design a Twitter ’
date: 2022-05-14 09:50:32
tags: 系统设计
categories:
00.What is Twitter
注:TimeLine 就是按照时间顺序显示的信息流
01. Functional Requirements
- 1.发布推特
- 2.删除推特
- 3.主页信息流
- 4.用户页面信息流
- 5.关注
- 6.搜索
- 7.点赞
…
02. Non-Functional Requirements
- 一致性
每次都能读取到最新的数据 - 可用性
每次刷新都不会报错,并不用求保证必须得到最新的数据,高可用性的前提是这个系统必须是可扩展的,保证系统在很多拥塞的时候,也能够很好的返回数据。 - Partition Tolerance(Fault Tolerance)
系统丢包了,或者有几个设备宕机了 或者有几个磁盘坏掉了 不影响系统运行
03. Assumption
关键指标
- 200m的DAU 100m的新推特
- 每个用户每天看timeline 5次,看别的用户timeline 3次
- 每个timeline 有20条数据
- 每个推特有280个字节(因为限制了每个推特是140个字符)
- 每个推特的元数据(发布时间 发布地点等等) 限制了是30个字节
- 20%的推特含有照片 每个照片200kb
- 10%的推特含有视频 30%的视频会被观看 每个视频2MB
存储估算
带宽估计
注:
- 200M 表示的是DAU
- 20表示的是每个Timeline显示的推特数量
04. API
注:
- readHomeTimeLine 中有的参数pageSize表示设定的每个page的推特数量,因为不同的终端屏幕大小不一样 需要显示的推特数量也不一样。pageToken表示当前的页码,如果不设定的话 默认显示最新的页号所对应的推特
05.High Level Design
Sceranio1 :Post twieets 发布推特
Sceranio2 :Visit Uesr TimeLine 访问用户的TimeLine
每次读取某个用户的timeline都比较费时间,可以采用的改进措施是采用Cache
.
- 用户每次发布推特的时候 把他最新的推特写入到cache
- 然后读取的时候 直接读取cache就可以了
Scenario3 Visit Home TimeLine
Pull Mode
- 同样的 如果采用的方式是用户从数据库里面query每个关注者的最新推特,然后把它们merge到一起,比较费时间,可以采用的方式也是
采用缓存
Push Mode
- 每个被关注的大V每次发布新推特的时候 把它写入到Cache里面每个粉丝follower的hometimeline里面 在图表里就是Fan out on Write
- 然后某个小粉丝读取的时候 直接读取Cache里面自己的hometimeline就可以了
上面对应了两种方式Pull Mode和Push Mode
分析一下利弊
注:Push Mode的劣势
1.每个用户发布新推特时候,写延迟更高
- 但是可以采用Async tasks异步的方式 写入每个小粉丝的home timeline
- 虽然这样会导致不同小粉丝的hometimeline 读取到更新推特的时间不一致 但是这个Eventual Consistency是可以接受的
- 如果是那种百万粉的大v,那么在发布新推特的时候 要写入百万个小粉丝的hometimeline 而且有一些粉丝可能还是僵尸粉以及不活跃的用户 那其实很耗费资源
- 可以采用下面这个Pull Mode和Push Mode结合的方式
Pull Mode & Push Mode(Hybrid Solution)
05. Low Level Design
06. Scalability
着重介绍分表(Sharding) 和缓存(Caching)