如何在系统架构时快速估计

如何在系统架构时快速估计

在面对大量数据时，无论是架构设计、可行性分析还是其他工程任务，通常需要的是严谨的分析。然而，很多场景下，尤其是即时问题的讨论，我们更需要的是快速、直接的估算。这样的数据虽然不需要精确，但依然可以给出量级上的大致认知，这比模糊的“海量”、“高吞吐”、“低延迟”等描述要清晰得多。

举个经典的例子，已知 Twitter 2020 年大约有 2000 亿 推文，推文吞吐量（TPS，事务每秒）是多少？网络带宽和存储容量需要多少？

看起来挺复杂的对吧？其实并不是。我们可以用一些快速估算技巧来求解，这些技巧简单易学，在某些场景下非常有价值。

估算的例子

我们来实际操作一下 Twitter 的问题。

吞吐量

首先，每个推文假设只写一次，那么，200,000,000,000 / 365 天 / 24 小时 / 60 分钟 / 60 秒 就能得出大致的吞吐量。

在估算时，通常来不及使用计算器，可以通过简化运算来加快速度：

• 365 天算多一点，近似为 400 天，这样 200 billion / 400 = 500 million
• 24 小时算多一点，近似为 25 小时，这样 500 million / 25 = 20 million
• 60 分钟算少一点，近似为 50 分钟，这样 20 million / 50 = 400 thousand
• 60 秒算少一点，近似为 50 秒，这样 400 thousand / 50 = 8000

通过这种方式，我们得出每秒 8000 个推文写入请求。熟练后，这个结果只需要半分钟就能得出。

另外，建议习惯使用英文中的 thousand、million、billion，数字每三位加一个逗号，这样与大多数技术文献中的格式保持一致。

另外，记住一天的秒数 86400，这个数值经常会用到。

如果使用计算器计算，结果大约是 6000 多个，估算的结果与实际计算相差无几。在工程设计中，只要估算结果与实际数值相差不超过一个量级，通常不会影响架构和设计决策。

带宽

接下来估算带宽。假设每条推文占用 200 字符，每个字符占 2 字节（byte），则每条推文占用 200 * 2 = 400 字节，因此带宽为 400 字节 * 8000 = 3,200,000 字节/秒，约为 3MB/秒。

此处也采用了估算。例如，从字节（byte）到千字节（KB）是 1024 倍，但可以近似为 1000 倍，从KB到MB同理。

存储

存储估算也是类似的。一年 200 billion 条推文 * 400 字节 = 80,000 GB = 80 TB。

这些估算让数据变得更加直观，有助于在设计系统时对容量和性能做出合理预判。

此外，我们可以根据需要调整估算数据。例如，在设计系统容量时，可以考虑处理峰值并预留一定的缓冲，简单地将结果乘以 5 来得到一个上限值；对于读写操作的吞吐量，我们可以将写操作结果乘以一个系数（例如 10）。

重要的数值

在上述过程中，可以看到一些常见的数值有助于快速估算，这些可以被视为工程中的“常识”或“基础”，帮助我们做出更合理的决策。

数据类型的空间占用

在很多系统中，数据类型的空间占用如下：

• Boolean: 1 字节
• 字符: 2 字节
• Integer/Float: 4 字节
• Long/Double: 8 字节

时间数量级

Jeff Dean 2009年有一个分享，讲解了重要的系统数值。以下是关于时间的一些常见数值（注意时间单位的关系：1秒 = 1000 毫秒 = 1,000,000 微秒 = 1,000,000,000 纳秒）：

• CPU 访问（包括缓存）：10 纳秒
• 内存访问：100 纳秒
• HDD 磁盘访问：10 毫秒，SSD 快约 100 倍
• HDD 吞吐量：100 MB/s，SSD 更高
• 同机房网络时延：1 毫秒
• 异地网络时延：10 毫秒
• 国际网络时延：100 毫秒

单机吞吐量上限

• Web 服务器 QPS：1000
• RDB 单机 QPS：1000
• NoSQL DB 磁盘单机 QPS：10K
• 内存访问单机 QPS：1M

如果你有其他重要的数值，也欢迎分享给我。

掌握这些技巧后，可以练习一些实际问题。例如，设计短网址系统时，假设每年有 1 billion 新网址被添加，估算读写服务的吞吐量、存储需求以及需要多少应用服务器。