在日常工作中,经常会遇到一些大促场景,需要评估系统的资源是否充足,是否需要增加资源,增加多少。
在系统设计面试中,有时也会遇到要求做一些估算类的题目:如果需要扛 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 的次幂
表格用处挺大,要收藏下来,用到的时候方便随时查看。