附录

约 5 分钟阅读

一些时候你会被要求做出保守估计。比如，你可能需要估计从磁盘中生成 100 张图片的缩略图需要的时间或者一个数据结构需要多少的内存。2 的次方表和每个开发者都需要知道的一些时间数据（译注：OSChina 上有这篇文章的译文）都是一些很方便的参考资料。

2 的次方表

Power           Exact Value         Approx Value        Bytes
---------------------------------------------------------------
7                             128
8                             256
10                           1024   1 thousand           1 KB
16                         65,536                       64 KB
20                      1,048,576   1 million            1 MB
30                  1,073,741,824   1 billion            1 GB
32                  4,294,967,296                        4 GB
40              1,099,511,627,776   1 trillion           1 TB

来源及延伸阅读

2 的次方

每个程序员都应该知道的延迟数

Latency Comparison Numbers
--------------------------
L1 cache reference                           0.5 ns
Branch mispredict                            5   ns
L2 cache reference                           7   ns                      14x L1 cache
Mutex lock/unlock                           25   ns
Main memory reference                      100   ns                      20x L2 cache, 200x L1 cache
Compress 1K bytes with Zippy            10,000   ns       10 us
Send 1 KB bytes over 1 Gbps network     10,000   ns       10 us
Read 4 KB randomly from SSD*           150,000   ns      150 us          ~1GB/sec SSD
Read 1 MB sequentially from memory     250,000   ns      250 us
Round trip within same datacenter      500,000   ns      500 us
Read 1 MB sequentially from SSD*     1,000,000   ns    1,000 us    1 ms  ~1GB/sec SSD, 4X memory
HDD seek                            10,000,000   ns   10,000 us   10 ms  20x datacenter roundtrip
Read 1 MB sequentially from 1 Gbps  10,000,000   ns   10,000 us   10 ms  40x memory, 10X SSD
Read 1 MB sequentially from HDD    30,000,000   ns   30,000 us   30 ms 120x memory, 30X SSD
Send packet CA->Netherlands->CA    150,000,000   ns  150,000 us  150 ms

Notes
-----
1 ns = 10^-9 seconds
1 us = 10^-6 seconds = 1,000 ns
1 ms = 10^-3 seconds = 1,000 us = 1,000,000 ns

基于上述数字的指标：

从磁盘以 30 MB/s 的速度顺序读取
以 100 MB/s 从 1 Gbps 的以太网顺序读取
从 SSD 以 1 GB/s 的速度读取
以 4 GB/s 的速度从主存读取
每秒能绕地球 6-7 圈
数据中心内每秒有 2,000 次往返

延迟数可视化

来源及延伸阅读

其它的系统设计面试题

常见的系统设计面试问题，给出了如何解决的方案链接

问题	引用
设计类似于 Dropbox 的文件同步服务	youtube.com
设计类似于 Google 的搜索引擎	queue.acm.org stackexchange.com ardendertat.com stanford.edu
设计类似于 Google 的可扩展网络爬虫	quora.com
设计 Google 文档	code.google.com neil.fraser.name
设计类似 Redis 的键值存储	实现键值存储系列 Amazon Dynamo 论文
设计类似 Memcached 的缓存系统	slideshare.net
设计类似亚马逊的推荐系统	hulu.com ijcai13.org
设计类似 Bitly 的短链接系统	n00tc0d3r.blogspot.com
设计类似 WhatsApp 的聊天应用	highscalability.com
设计类似 Instagram 的图片分享系统	highscalability.com highscalability.com
设计 Facebook 的新闻推荐方法	quora.com quora.com slideshare.net
设计 Facebook 的时间线系统	facebook.com highscalability.com
设计 Facebook 的聊天系统	erlang-factory.com facebook.com
设计类似 Facebook 的图表搜索系统	facebook.com facebook.com facebook.com
设计类似 CloudFlare 的内容传递网络	cmu.edu
设计类似 Twitter 的热门话题系统	michael-noll.com snikolov .wordpress.com
设计一个随机 ID 生成系统	blog.twitter.com github.com
返回一定时间段内次数前 k 高的请求	ucsb.edu wpi.edu
设计一个数据源于多个数据中心的服务系统	highscalability.com
设计一个多人网络卡牌游戏	indieflashblog.com buildnewgames.com
设计一个垃圾回收系统	stuffwithstuff.com washington.edu
设计 API 限流器	Stripe：限流器设计
设计证券或数字资产交易所（如 NASDAQ、Binance）	Jane Street 讲座 Go 交易引擎实现 Go 限价订单簿实现
添加更多的系统设计问题	贡献

真实架构

关于现实中真实的系统是怎么设计的文章。

Source: Twitter timelines at scale

不要专注于以下文章的细节，专注于以下方面：

发现这些文章中的共同的原则、技术和模式。
学习每个组件解决哪些问题，什么情况下使用，什么情况下不适用
复习学过的文章

类型	系统	引用
Data processing	MapReduce - Google的分布式数据处理	research.google.com
Data processing	Spark - Databricks 的分布式数据处理	slideshare.net
Data processing	Storm - Twitter 的分布式数据处理	slideshare.net

Data store	Bigtable - Google 的列式数据库	harvard.edu
Data store	HBase - Bigtable 的开源实现	slideshare.net
Data store	Cassandra - Facebook 的列式数据库	slideshare.net
Data store	DynamoDB - Amazon 的文档数据库	harvard.edu
Data store	MongoDB - 文档数据库	slideshare.net
Data store	Spanner - Google 的全球分布数据库	research.google.com
Data store	Memcached - 分布式内存缓存系统	slideshare.net
Data store	Redis - 能够持久化及具有值类型的分布式内存缓存系统	slideshare.net

File system	Google File System (GFS) - 分布式文件系统	research.google.com
File system	Hadoop File System (HDFS) - GFS 的开源实现	apache.org

Misc	Chubby - Google 的分布式系统的低耦合锁服务	research.google.com
Misc	Dapper - 分布式系统跟踪基础设施	research.google.com
Misc	Kafka - LinkedIn 的发布订阅消息系统	slideshare.net
Misc	Zookeeper - 集中的基础架构和协调服务	slideshare.net
	添加更多	贡献

公司的系统架构

Company	Reference(s)
Amazon	Amazon 的架构
Cinchcast	每天产生 1500 小时的音频
DataSift	每秒实时挖掘 120000 条 tweet
DropBox	我们如何缩放 Dropbox
ESPN	每秒操作 100000 次
Google	Google 的架构
Instagram	1400 万用户，达到兆级别的照片存储是什么在驱动 Instagram
Justin.tv	Justin.Tv 的直播广播架构
Facebook	Facebook 的可扩展 memcached TAO: Facebook 社交图的分布式数据存储 Facebook 的图片存储 Facebook Live 如何同时向 80 万观众直播
Flickr	Flickr 的架构
Mailbox	在 6 周内从 0 到 100 万用户
Netflix	Netflix 全栈架构概览按下播放键后发生了什么
Pinterest	从零到每月数十亿的浏览量 1800 万访问用户，10 倍增长，12 名员工
Playfish	月用户量 5000 万并在不断增长
PlentyOfFish	PlentyOfFish 的架构
Salesforce	他们每天如何处理 13 亿笔交易
Stack Overflow	Stack Overflow 的架构
TripAdvisor	40M 访问者，200M 页面浏览量，30TB 数据
Tumblr	每月 150 亿的浏览量
Twitter	Making Twitter 10000 percent faster 每天使用 MySQL 存储2.5亿条 tweet 150M 活跃用户，300K QPS，22 MB/s 的数据流可扩展时间表 Twitter 的大小数据 Twitter 运维：扩展到超过 1 亿用户 Twitter 如何每秒处理 3,000 张图片
Uber	Uber 如何扩展自己的实时化市场 Uber 扩展到 2,000 名工程师、1,000 个服务与 8,000 个 Git 仓库的经验
WhatsApp	Facebook 用 190 亿美元购买 WhatsApp 的架构
YouTube	YouTube 的可扩展性 YouTube 的架构

公司工程博客

你即将面试的公司的架构

你面对的问题可能就来自于同样领域

来源及延伸阅读

想添加工程博客？为避免重复维护，可以考虑将公司博客加入下面的仓库：

kilimchoi/engineering-blogs