搞定系统设计 02:估算的一些方法

在日常工作中,经常会遇到一些大促场景,需要评估系统的资源是否充足,是否需要增加资源,增加多少。

在系统设计面试中,有时也会遇到要求做一些估算类的题目:如果需要扛 100w QPS,需要多少机器……

想要做到“准确”的估算,需要对数字有一定的感觉。

第二章主要讲的就是一些常用的数字。本文最后也会附加一些笔者平时积累的数字。

2 的次幂

2的次幂

英语里面常讲 1 个 Million,1 个 Billion,分别是百万、十亿的意思。可以看到,以 3 个 0 为一组,层层递进。

千-百万-十亿

每个程序员都要了解的延迟数字

这里有一张表格反映了一些计算机的典型操作的耗时,配套的还有一个可视化网站,这个其实见得比较多了。

latency number tables

图形化的网页上可以选择年份,数据也更准确。

latency number graph

从中可以得出一些明显的结论:

  • 内存比磁盘快。
  • 避免 disk seek。
  • 数据中心常常位于不同的区域,在它们之间传送数据比较耗时。
  • 从磁盘顺序读数据比从网络顺序读数据慢。

可用性数字

工作中,我们常用几个 9 来形容一个系统的可用性。100% 表示一个系统永远不会挂,实际中的系统可用性指标大多处于 99% -100% 之间。

像一些云厂商,如 Amazon,Microsoft,Google 承诺的可用性是 3 个 9,即 99.9% 或以上,描述的是可用时间。

可用性

我的一些数字积累

  • 某支付服务的支付峰值 60w QPS
  • Go GC 打开写屏障需要花费 10-30us
  • 内网中,一次网络请求的耗时是 ms 级别
  • 万兆网卡,1.25GB/s 打满
  • 4C8G 建 10w 到 20w 的连接没有问题
  • 因为机械硬盘的机械结构,随机 I/O 与顺序的 I/O 性能可能相差几百倍。固态硬盘则只有十几倍到几十倍之间
  • twitter 工程师认为,良好体验的网站平均响应时间应该在 500ms 左右,理想的时间是 200-300ms
  • 平均 QPS:日平均用户请求除以 4w。日平均用户请求,一般来自产品的评估。峰值 QPS:平均 QPS 的 2~4 倍

实战

本章最后有一个实战的例子:评估 twitter 的 QPS 和存储容量。

先给出了一些预设:

  • 300 个 million 的月活跃用户
  • 50% 的用户每天都使用 twitter
  • 用户平均每天发表 2 条 tweets
  • 10% 的 tweets 包含多媒体
  • 多媒体数据保存 5 年

下面是估算的过程:

先预估 QPS:

  • DAU(每天的活跃用户数,Daily Active Users)为:300 million(总用户数) * 50% = 150 million
  • 发 tweets 的平均 QPS:150 million * 2 / 24 hour / 3600 second = ~3500
  • 高峰期 QPS 一般认为是平均 QPS 的 2 倍:2 * 3500 = 7000 QPS

再来估算存储容量:

假设多媒体的平均大小为 1MB,那么每天的存储容量为:150 million * 2 * 10% * 1MB = 30 TB。5 年的存储容量为 30 TB * 365 * 5 = 55 PB。

最后这两个的估算过程是这样的:

300 个 million * 10%* 1MB,1 MB 其实就是 6 个 0,相当于 million 要进化 2 次:million -> billion -> trillion,即从 M -> G -> T,于是结果等于 300 T * 10% = 30 T。

30 TB * 365 * 5 = 30 TB * 1825 = 30 TB * 10^3 * 1.825,TB 进化一次变成 PB,于是等于 30 * 1.825 PB = 55 PB。

一些建议

估算题的精髓在于过程,解决问题的过程比得到一个正确的结果更重要。

  • 粗算。面试过程中,得到一个精确结果的意义不大,没那么多时间且没必要。例如 99987 / 9.1 可以简化为 100,000 / 10
  • 写下过程中所做的假设,方便之后参考。
  • 写下单位。例如 5MB,这会在后面的估算环节用到。
  • 经常被问到的估算:QPS、峰值 QPS、存储容量、服务器个数……

点评

估算能力还是挺重要的,日常工作中也用得到。例如新增一个 redis,评估一下需要多少台机器资源……如果遇到这样的场景,应该抓住机会锻炼一下。

本章给出的 2 的次幂表格用处挺大,要收藏下来,用到的时候方便随时查看。