2 封底估算
在系统设计面试中，有时会要求你使用 "封底估算"（back-of-the-envelope estimation）来估算系统容量或性能需求。根据谷歌高级研究员杰夫-迪恩（Jeff Dean）的说法，"封底估算是你结合思想实验和常见性能数字进行的估算，目的是让你对哪些设计能满足你的要求有一个良好的感觉"。
2.1 常用单位
| 2的方次 | 近似值 | 全称 | 简称 |
|---|---|---|---|
| 10 | Thousand | 千字节(Kilobyte) | KB |
| 20 | Million | 兆字节(Megabyte) | MB |
| 30 | Billion | 千兆字节(Gigabyte) | GB |
| 40 | Trillion | 太字节(Terabyte) | TB |
| 50 | Quadrillion | 百亿字节(Petabyte) | PB |
2.2 延迟
来自谷歌的迪恩博士揭示了 2010 年典型计算机操作的时长。随着计算机速度越来越快、功能越来越强大，有些数字已经过时。不过，这些数字仍能让我们了解不同计算机操作的快慢。
| 操作 | 时间 |
|---|---|
| L1缓存 | 0.5ns |
| 分支误预测 | 5ns |
| 二级缓存 | 7ns |
| 互斥锁定/解锁 | 100ns |
| 主内存引用 | 100ns |
| Zippy压缩1K字节 | 10 μs |
| 1Gbps网络发送2K字节 | 20 μs |
| 内存顺序读取1MB | 250μs |
| 同一数据中心内往返 | 500μs |
| 磁盘寻道 | 10ms |
| 网络顺序读取1MB | 10ms |
| 磁盘顺序读取1MB | 30ms |
| 发送数据包CA(California)->Netherlands->CA | 150ms |
谷歌的一名软件工程师制作了一个工具，将Dean博士的数字可视化。该工具还考虑了时间因素。下图显示了截至 2020 年的可视化延迟数字（数字来源：参考资料 https://colin-scott.github.io/personal_website/research/interactive_latency.html ）。
- 内存速度快，但磁盘速度慢。
- 尽可能避免磁盘寻道。
- 简单的压缩算法速度快。
- 尽可能在通过互联网发送数据前对其进行压缩。
- 数据中心通常位于不同地区，在它们之间发送数据需要时间。
2.3 可用性数字
高可用性是指系统在理想的长时间内持续运行的能力。高可用性是以百分比来衡量的，100%表示服务没有停机时间。大多数服务介于99%和100%之间。
服务水平协议（SLA：service level agreement）是服务提供商的常用术语。这是您（服务提供商）与客户之间的协议，该协议正式规定了您的服务将提供的正常运行时间水平。云服务提供商亚马逊、谷歌和微软将其 SLA 定义为 99.9% 或以上。正常运行时间传统上以9为单位。9越多越好。
参考资料
- 软件测试精品书籍文档下载持续更新 https://github.com/china-testing/python-testing-examples 请点赞，谢谢！
- 本文涉及的python测试开发库 谢谢点赞！ https://github.com/china-testing/python_cn_resouce
- python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
- Linux精品书籍下载 https://www.cnblogs.com/testing-/p/17438558.html
- https://www.drawio.com/doc/faq/
- 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
-
System design primer: https://github.com/donnemartin/system-design-primer
-
Latency Numbers Every Programmer Should Know:
https://colin-scott.github.io/personal_website/research/interactive_latency.html
- Amazon Compute Service Level Agreement:
https://aws.amazon.com/compute/sla/
- Compute Engine Service Level Agreement (SLA):
https://cloud.google.com/compute/sla
- SLA summary for Azure services: https://azure.microsoft.com/en-us/support/legal/sla/summary/
2.4 实例：估算新浪微博QPS和存储需求
请注意以下数字仅用于本练习，并非新浪微博的真实数字。
假设
- 3亿月活跃用户。
- 50%的用户每天使用。
- 用户平均每天发布2条微博。
- 10%的微博包含媒体内容。
- 数据存储 5 年。
估计值：
每秒查询次数 (QPS Query per second) 估计值：
- 日活跃用户(DAU Daily active users) = 3亿 * 50% = 1.5亿
- 博文QPS = 1.5亿*2条推文/24小时/3600秒 = ~3500
- 峰值QPS =2*QPS = ~7000
我们在此仅估算媒体存储量。
- 平均微博大小
- weibo_id 64 字节
- 文本 140 字节
- 媒体 1 MB
- 媒体存储量 每天1.5亿 * 2 * 10% * 1 MB = 30TB
- 5年媒体存储： 30TB * 365 * 5 = ~55PB
2.5 面试小结
封底估算的关键在于过程。解决问题比获得结果更重要。面试官可能会测试你解决问题的能力。以下是一些应遵循的技巧：
-
圆周率和近似值。面试时很难进行复杂的数学运算。例如，"99987/ 9.1"的结果是什么？没有必要花费宝贵的时间来解决复杂的数学问题。不要求精确。使用整数和近似值对你有利。除法问题可简化如下： "100,000/10".
-
写下你的假设。最好写下你的假设，以便日后参考。文章来源：https://www.toymoban.com/news/detail-683962.html
-
标注单位。写下 "5 "时，是指 5 KB 还是 5 MB？这可能会让你感到困惑。写下单位，因为 "5 MB "有助于消除歧义。文章来源地址https://www.toymoban.com/news/detail-683962.html
到了这里，关于系统设计(架构师)指南2封底估算&新浪微博实例的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
