第 2 章：粗略估算
引言
粗略估算是系统设计面试中的重要技能：通过快速计算大致评估系统容量或性能。Google 高级研究员 Jeff Dean 指出，这类估算有助于结合思想实验和常见的性能基准，判断设计能否满足需求。
本章介绍关键概念、方法和示例，帮助读者掌握可扩展性分析与估算。
第 1 节：关键概念
2 的幂
理解以 2 的幂表示的数据量是基础：
这有助于准确估算存储空间和带宽。
每位程序员都应了解的延迟数据
延迟是计算系统执行各类操作所需的时间，可用于比较相对性能：
| 操作 | 延迟（2020 年） |
|---|---|
| 访问 L1 缓存 | 0.5 ns |
| 访问 L2 缓存 | 7 ns |
| 访问主内存 | 100 ns |
| SSD 随机读取 | 150 µs |
| HDD 随机寻道 | 10 ms |
| 数据中心内往返 | 500 µs |
| 跨区域数据中心通信 | 150 ms |
关键认识：
- 内存快，磁盘慢。
- 尽可能避免磁盘寻道。
- 通过互联网传输数据前先压缩，以节省带宽。
可用性数据
高可用性（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 等云服务商通常以 99.9% 或更高的服务等级协议（SLA）为目标。
第 2 节：估算示例——Twitter 的 QPS 与存储需求
假设
- 月活跃用户（MAU）3 亿。
- 日活跃用户（DAU）占 50%。
- 每位用户每天平均发布 2 条推文。
- 10% 的推文包含媒体。
- 数据保留 5 年。
估算
每秒查询量（QPS）：
- DAU = ( 300M x 50% = 150M )
- 推文写入 QPS = ( 150M x 2 条推文 / 24 小时 / 3600 秒 ≈ 3500 )
- 峰值 QPS = ( 2 x 3500 ≈ 7000 )
媒体存储：
- 推文大小的组成：
tweet_id：64 字节text：140 字节media：1 MB
- 每日媒体存储量： ( 150M x 2 x 10% x 1MB = 30TB/天 )
- 5 年存储量： ( 30TB x 365 x 5 ≈ 55PB )
- 推文大小的组成：
缓存需求（沿用上面的假设并补充）：
- 补充假设： 每位 DAU 每天阅读 100 条推文，且符合二八定律（20% 的推文承担 80% 的读取）。
- 每日读取量： ( 150M x 100 = 150 亿 ) 次推文读取
- 读取 QPS： ( 150 亿 / 86400 ≈ 175,000 )；峰值读取 QPS = ( 2 x 175,000 ≈ 350,000 )
- 单条推文文本大小：
tweet_id+text= 64 + 140 ≈ 200 字节（媒体由 CDN 提供，不放在此缓存中） - 每日读取数据量： ( 150 亿 x 200B = 3TB )
- 只缓存热点 20%： ( 3TB x 20% ≈ 600GB )
- 机器数量： 每个缓存节点按约 64GB 可用内存计，( 600GB / 64GB ≈ 10 ) 台；为热点 key 的副本和余量留出空间，取约 12 台。
服务器数量：
- 峰值负载： ( 350,000（读）+ 7,000（写）≈ 350,000 QPS )
- 假设单台服务器容量： 约 5,000 QPS（16 核应用服务器处理轻量请求；实际应通过压测确定）
- 所需服务器数： ( 350,000 / 5,000 = 70 ) 台
- 预留约 30% 余量以应对故障和发布： ( 70 x 1.3 ≈ 90 ) 台
- 合理性检查： 缓存命中（内存读取约 100 ns）能让单次请求延迟保持很低；若命中率下降，请求会落到数据库，单台 QPS 的假设就不再成立。
第 3 节：有效估算的技巧
1. 四舍五入与近似
不必追求精确数字，重点在估算过程。用整数字简化复杂计算。例如：
- ( 99987 / 9.1 ) 可以近似为 ( 100,000 / 10 = 10,000 )。
2. 写下假设
清楚记录假设，方便后续参考。
3. 标明单位
为避免歧义，应写 5 MB，而不只写 5。
4. 常见估算场景
- QPS（每秒查询量）： 衡量流量强度。
- 峰值 QPS： 考虑流量突增。
- 存储需求： 估算总数据量。
- 缓存需求： 评估缓存所需内存。
- 服务器数量： 根据工作负载计算硬件需求。