2. Back-of-the-envelope Estimation #
封底估算
📝 封底估算是系统设计中评估性能需求和系统容量的重要技巧。
重点需掌握：
- 数据单位换算：KB、MB、GB等，每级相差约1000倍
- 常见操作延迟数据，如内存访问快、磁盘访问慢
- 可用性级别：99.9%和99.99%的差异
- 封底估算方法：基于合理假设，关注QPS、存储等指标，注重计算过程而非精确结果。
在系统设计面试中，你有时会被要求估算性能需求或系统容量。
根据谷歌高级研究员Jeff Dean的说法，，“封底估算是你将想象中的实验和常见性能指标数据结合而得出的一些估算值，这些值使你对何种设计可以满足系统需求有初步的概念”
为了有效地进行这种估算，应该了解几种机制。
2.1 2的幂 #
数据量可能变得非常庞大，但计算归结为基本原理。 对于精确的计算，你需要了解2的幂，它对应于给定的数据单位：
| 2的幂 | 近似值 | 全称 | 缩写 |
|---|---|---|---|
| 2^10 | 1000 | 1 Kilobyte | 1 KB |
| 2^20 | 1,000,000 | 1 Megabyte | 1 MB |
| 2^30 | 1,000,000,000 | 1 Gigabyte | 1 GB |
| 2^40 | 1,000,000,000,000 | 1 Terabyte | 1 TB |
| 2^50 | 1,000,000,000,000,000 | 1 Petabyte | 1 PB |
📝 2^10到2^20增加了10个幂次
每次增加单位就向上转换（KB -> MB -> GB -> TB -> PB），并且每次增加的数量大约是上一单位的1000倍（即2^10, 1024）
2.2 每个程序员都应该知道的延迟数字 #
Jeff Dean创建了一个著名的典型计算机操作耗时表。
由于硬件的发展，这些数字可能有点过时，但它们仍然给出了操作之间良好的相对度量：
以下是表格内容的识别结果，并将第一列翻译成中文后输出为Markdown表格：
| 操作名称 | 耗时 |
|---|---|
| L1缓存访问 | 0.5 ns |
| 分支预测错误 | 5 ns |
| L2缓存访问 | 7 ns |
| 互斥锁加锁/解锁 | 100 ns |
| 内存访问 | 100 ns |
| 使用Zippy压缩1KB数据 | 10,000 ns = 10 μs |
| 在1Gbps网络上传输2KB 数据 | 20,000 ns = 20 μs |
| 从内存中顺序读取1MB数据 | 250,000 ns = 250 μs |
| 同一数据中心内的往返 | 500,000 ns = 500 μs |
| 磁盘寻道 | 10,000,000 ns = 10 ms |
| 从网络顺序读取1MB数据 | 10,000,000 ns = 10 ms |
| 从磁盘顺序读取1MB数据 | 30,000,000 ns = 30 ms |
| 将数据包从加州发送到荷兰，再从荷兰返回加州 | 150,000,000 ns = 150 ms |
📝 ns、μs、ms
ns：纳秒（Nanosecond），即十亿分之一秒(10^-9)
μs：微秒（Microsecond），即百万分之一秒(10^-6)
ms：毫秒（Millisecond），即千分之一秒(10^-3)
1 毫秒 (ms) = 1,000 微秒 (μs)
1 微秒 (μs) = 1,000 纳秒 (ns)
1 毫秒 (ms) = 1,000,000 纳秒 (ns)
图2.1 上面内容的可视化呈现：
以上数字得出的一些结论：
- 内存速度快，磁盘速度慢(考虑SSD的话硬盘速度也慢)
- 如果可能，应避免磁盘寻道(考虑SSD的话应避免在硬盘中查找数据)
- 压缩通常很快
- 如果可能，在通过网络发送数据之前进行压缩
- 数据中心往返开销很大
2.3 可用性数字 #
高可用性是指系统长时间持续运行的能力。换句话说，最大限度地减少停机时间。
通常，服务的目标可用性范围为99%到100%。
SLA是服务提供商和客户之间的正式协议。它正式定义了你的服务需要支持的正常运行时间级别。
云服务提供商通常将其正常运行时间设置为99.9%或更高。例如，AWS EC2的 SLA为99.99%。
以下是基于不同SLA的允许停机时间：
| 可用性（百分比） | 每天不可用时长 | 每年不可用时长 |
|---|---|---|
| 99% | 14.40 分钟 | 3.65 天 |
| 99.9% | 1.44 分钟 | 8.77 小时 |
| 99.99% | 8.64 秒 | 52.60 分钟 |
| 99.999% | 864.00 毫秒 | 5.26 分钟 |
| 99.9999% | 86.40 毫秒 | 31.56 秒 |
2.4 案例: 估算Twitter的QPS和存储需求 #
下面的数据是针对这个练习而设置的，并非推特的真实数据。
假设:
- 3亿月活跃用户(MAU)
- 50%的用户每天使用Twitter
- 用户平均每天发布2条推文
- 10%的推文包含媒体
- 数据存储5年
估算：
- 估算QPS(每秒查询量)
- 每日活跃用户(DAU)=300,000,000 * 0.5 = 150,000,000 (1.5亿)
- 推文QPS=150,000,000 * 2 / 24 / 3600 = 3500
- 峰值QPS=2 * 3500 = 7000
- 每天的多媒体存储量
- 平均推文大小
- tweet_id 64bytes
- text 140 bytes
- media 1MB
- 多媒体数据存储量=150,000,000 * 2 * 10% * 1MB = 30TB天
- 平均推文大小
- 5年的多媒体数据存储量 = 30TB * 365 * 5 ≈ 55PB
2.5 小技巧 #
封底估算重在过程，而非结果。面试官可能会借此考察你的问题解决能力。
一些需要考虑的技巧：
- 四舍五入和近似: 不要尝试计算
99987/9.1，而是将其四舍五入为100000/10，这样更容易计算。 - 在进行估算之前，写下你的假设。
- 明确标出单位。例如写5MB而不是5。
- 常见的封底估算指标包括：QPS、峰值QPS、存储大小、缓存大小、服务器的数量等。