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

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

在系统设计面试中，搞定估算有时也会遇到要求做一些估算类的系统题目：如果需要扛 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 的次幂表格用处挺大，要收藏下来，用到的时候方便随时查看。