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