第 2 章 粗略估算

引言

粗略估算（Back-of-the-Envelope Estimation）是系统设计面试中的一项关键技能。它是指通过快速、粗略的计算来评估系统的容量或性能。按照 Google 高级研究员 Jeff Dean 的说法，这类估算借助思想实验和常见的性能基准，帮助我们判断设计是否满足需求。

本章介绍相关的关键概念、方法和示例，帮助你熟练掌握可扩展性分析与估算。

1. 关键概念

2 的幂

用 2 的幂来理解数据量是一项基本功：

掌握这些知识有助于准确地计算存储和带宽。

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

延迟数字表示计算机系统中各类操作所需的时间。它们能让我们了解不同操作之间的相对性能：

关键结论：

• 内存快，磁盘慢。
• 尽可能避免磁盘寻道。
• 在通过互联网传输数据之前先压缩，以节省带宽。

可用性数字

高可用（High Availability，HA）意味着尽可能少的停机时间。可用性用「几个 9」来表示：

• 99%（两个 9）： 每年约 3.65 天停机
• 99.9%（三个 9）： 每年约 8.8 小时停机
• 99.99%（四个 9）： 每年约 52 分钟停机
• 99.999%（五个 9）： 每年约 5.3 分钟停机
• 99.9999%（六个 9）： 每年约 31.56 秒停机

Amazon、Google 和 Microsoft 等云服务商的服务等级协议（Service Level Agreement，SLA）目标是 99.9% 或更高。

2. 估算示例：Twitter 的 QPS 与存储需求

假设

• 月活跃用户（MAU）3 亿。
• 50% 为日活跃用户（DAU）。
• 每位用户每天平均发推数： 2。
• 10% 的推文包含媒体。
• 数据保留期： 5 年。

估算

1. 每秒查询数（QPS）：

   • DAU = \( 300M x 50\% = 150M \)
   • 推文 QPS = \( 150M x 2 tweets / 24 hour / 3600 seconds = ~3500 \)
   • 峰值 QPS = \( 2 x 3500 = ~7000 \)

2. 媒体存储：

   • 推文大小的组成：
     • tweet_id：64 字节
     • text：140 字节
     • media：1 MB
   • 每日媒体存储： \( 150M x 2 x 10\% x 1MB = 30TB per day \)
   • 5 年存储： \( 30TB x 365 x 5 = ~55PB \)

3. 高效估算的技巧

1. 取整与近似

精确度并不关键，重点在于过程。用整数来简化复杂的计算。例如：

• \( 99987 / 9.1 \) 可以近似为 \( 100,000 / 10 = 10,000 \)。

2. 写下假设

把假设清晰地记录下来，方便后续参考。

3. 标注单位

标注单位以避免歧义（例如写 5 MB，而不是 5）。

4. 常见的估算场景

• QPS（每秒查询数）： 衡量流量强度。
• 峰值 QPS： 考虑流量高峰。
• 存储需求： 估算总的数据量需求。
• 缓存需求： 评估缓存所需的内存。
• 服务器数量： 根据工作负载计算硬件需求。