CHAPTER 2: BACK-OF-THE-ENVELOPE ESTIMATION
在系统设计面试中，有时您会被要求估计系统容量或使用粗略估计的性能需求。根据杰夫·迪恩的说法，谷歌高级研究员，“粗略的计算是你使用结合思想实验和常见的性能数字，以获得良好的感觉,哪些设计能满足你的要求?[1]
您需要对可伸缩性基础知识有很好的了解，才能有效地执行系统的后端估计。以下概念应该很好地理解:两个two[2]的幂;每个程序员都应该知道延迟数和可用性数。
2的幂 Power of two
尽管在处理分布式系统时数据量会变得非常大，所有的计算都归结为基础。为了得到正确的计算，关键是要知道数据体积单位采用2的幂。一个字节是由8位组成的序列。ASCII字符
使用一个字节的内存(8位)。下表解释了数据量单位.
| 幂 | 近似值 | 全名 | 短名称 |
|---|---|---|---|
| 10 | 1000年 | 前字节 | 1KB |
| 20 | 百万年 | 兆字节 | 1MB |
| 30 | 10万亿年 | GB字节 | 1GB |
| 40 | 1万亿年 | TB字节 | 1TB |
| 50 | 1000万亿年 | PB字节 | 1PB |
每个程序员都应该知道延迟数据 Latency numbers every programmer should know
谷歌的Dean博士揭示了2010年典型计算机操作的时长[1]。一些随着计算机变得更快、更强大，数字已经过时了。然而,这些数字应该还是能给我们一个快慢不同的概念电脑操作。
| 操作名称 | 时间 |
|---|---|
| 1级缓存引用 | 0.5ns |
| 分支 mispredict | 5ns |
| 2级缓存引用 | 7ns |
| 互斥锁/解锁 | 100ns |
| 主存引用 | 100ns |
| 用zippy压缩1k字节 | 10,000ns=10μs |
| 通过1GB网络传输2KB字节 | 20,000ns = 20μs |
| 内存按照顺序读取1MB | 250,000ns=250μs |
| 同一个数据中心内的往返 | 500,000ns = 500μs |
| 磁盘寻找 | 10,000.000ns=10ms |
| 从网络中读取1MB | 10,000.000ns=10ms |
| 从硬盘中读取1MB | 30,000.000ns=30ms |
| 发送数据包CA(加利福尼亚)->荷兰->CA | 150,000.000ns=150ms |
笔记
Ns =纳秒，
µs =微秒，
ms =毫秒
1秒= 10^-9秒 1µs= 10^-6秒= 1,000 ns 1毫秒= 10^-3秒=1,000µs = 1,000,000毫秒
谷歌的一位软件工程师开发了一个工具，将迪恩博士的数据可视化。这个工具还需要考虑到时间因素。截止年的可视化时延数字如figure2-1所示 2020年(数据来源:参考资料[3])。
通过分析图2-1中的数字，我们可以得出以下结论:
- 内存快，磁盘慢。
- 尽可能避免磁盘查找。
- 简单的压缩算法速度快。
- 如果可能的话，在通过互联网发送数据之前压缩数据。
- 数据中心通常位于不同的区域，数据在数据中心之间传输需要一定的时间。
可用性数据 Availability numbers
高可用性是系统在理想的长时间内持续运行的能力一段时间。高可用性是以百分比来衡量的，100%意味着服务可以零停机时间。大多数服务都在99%到100%之间。服务水平协议(SLA)是服务提供者常用的术语。这是一个您(服务提供商)与您的客户之间的协议，以及本协议正式定义服务将交付的正常运行时间级别。云提供商亚马逊[4]，谷歌[5]和Microsoft[6]将它们的sla设置为99.9%或更高。正常运行时间通常是用九来衡量。9越多越好。如表2-3所示9与预期的系统停机时间相关。
| 可用性 | 每天停机时间 | 每年停机时间 |
|---|---|---|
| 99% | 14.40分钟 | 3.65日 |
| 99.9% | 1.44分钟 | 8.77小时 |
| 99.99% | 8.64秒 | 52.60分钟 |
| 99.999% | 864毫秒 | 5.62分钟 |
| 99.9999% | 86.4毫秒 | 31.56秒 |
示例:估计Twitter QPS和存储需求请注意，以下数字仅用于此练习，
因为它们不是实数从Twitter。
假设:
• 3亿月活跃用户。
• 50%的用户每天使用Twitter。
• 用户平均每天发布2条tweet。
• 10%的推文包含媒体内容。
• 数据存储5年。
估计:
每秒查询(QPS)估计:
• 日活跃用户(DAU) = 3亿* 50% = 1.5亿
• 推文QPS = 1.5亿* 2条推文/ 24小时/ 3600秒= ~3500
• Peek QPS = 2 * QPS = ~7000
这里我们只估算媒体存储空间。
• 平均tweet大小:
• tweet_id 64字节
• 文本140字节
• 媒体1mb
• 媒体存储:1.5亿* 2 * 10% * 1mb = 30tb /天
• 5年介质存储:30tb * 365 * 5 = ~ 55pb
提示 Tips
粗略估计是关于过程的。解决问题更重要比取得成果更重要。面试官可能会测试你解决问题的能力。
这里有以下是一些建议:
- 舍入和近似。做复杂的数学运算很困难在面试中。例如，“99987 / 9.1”的结果是什么?没有必要花宝贵的时间解决复杂的数学问题。精度不被期望。使用对你有利的四舍五入和近似值。除法问题可以是简化为:“100,000 / 10”。
- 写下你的假设。把你的假设写下来是个好主意后引用。
- 标注你的单位。当你写下“5”时，它的意思是5 KB还是5 MB?你可能会把自己弄糊涂。写下单元，因为“5mb”有助于删除歧义。
- 常用的粗略估计:QPS、峰值QPS、存储、缓存、服务器数量等。你可以在准备考试时练习这些计算方法面试。熟能生巧。
恭喜你走了这么远!现在给自己点鼓励吧。好工作!
参考资料
[1] J. Dean.Google Pro Tip: Use Back-Of-The-Envelope-Calculations To Choose The Best
Design:
http://highscalability.com/blog/2011/1/26/google-pro-tip-use-back-of-the-envelope-calculations-to-choo.html
[2] System design primer: https://github.com/donnemartin/system-design-primer
[3] Latency Numbers Every Programmer Should Know:
https://colin-scott.github.io/personal_website/research/interactive_latency.html
[4] Amazon Compute Service Level Agreement:
https://aws.amazon.com/compute/sla/
[5] Compute Engine Service Level Agreement (SLA):
https://cloud.google.com/compute/sla
[6] SLA summary for Azure services: https://azure.microsoft.com/en-us/support/legal/sla/summary
