当前位置：首页 > news >正文

系统设计基本功：流量与存储需求估算

news 来源：原创 2025/6/14 19:58:02

欢迎来到啾啾的博客🐱。
记录学习点滴。分享工作思考和实用技巧，偶尔也分享一些杂谈💬。
有很多很多不足的地方，欢迎评论交流，感谢您的阅读和评论😄。

引言

总所周知，没有评估就没有调优，而没有标准就不能评估。

系统最基础的估算就是流量估算与存储需求。

流量估算有以下三种统计指标：

每秒事务数-TPS (Transaction per Second)
TPS是衡量信息系统吞吐量的最终标准。每秒钟原子操作的次数。
每秒请求数-HPS (Hit per Second)
HPS从指客户端发向服务端的请求数，client->server的次数。
不等同于web点击数，一个web点击可能向server发送多个请求。
每秒查询数-QPS (Query per Second)
QPS是指一台服务器能够响应的查询次数。

存储需求则一般与流量紧密结合。

资料引用：《搞定系统设计》

一、如何估算系统流量？

经典练习

一个经典的练习，假设：

推特有3亿月活用户。
50%的用户每天都使用推特。
用户平均每天发两条推文。
10%的推文包含多媒体数据。
数据要存储5年。

要怎么估算发贴模块QPS与存储需求？

估算QPS

每日活跃用户（DAU）=300000000 x 50% = 1.5亿
推文QPS=150000000 x 2 / 24小时 / 3600 秒 ≈ 3500
峰值QPS=2 x 推文QPS ≈ 7000

估算存储需求

平均推文大小：
- tweet_id:64字节
- 文本:140字节
- 多媒体文件:1MB
多媒体数据存储量=150000000 x 2 x 10% x 1MB = 30TB/天
五年的多媒体数据存储量 = 30TB x 365 x5 ≈ 55PB

一般来说QPS是<=TPS的，还是以推文QPS为例。
用户发推文=发推文+更新后台数据+其他…
此时 TPS ≈ 2 x QPS。

用户发推文需要点击一下，此时
HPS = QPS

估算小技巧

估算是一个大致的操作。只需要依据行为抽象、大致存储大小进行大致估算就可以了。
比如大小没必要真的按照1024去计算，1000也是可以的。

二、估算对应的服务器需求

基础（技术栈）
以主流的Linux系统为基础进行估算，在Java21之前，我们的Java线程和操作系统内核线程是**一对一模型（1:1 Threading）。
性能基准: 在估算前，最理想的情况是通过压力测试获取API的基础信息，如果无法测试，则需要基于经验做出明确的假设：
- 单次请求平均CPU消耗时间。
- 单次请求平均内存消耗。
- 数据库交互模式（读写次数、事务复杂度等）。

使用QPS估算服务器配置

服务器CPU

主要是需要考虑服务器CPU和内存配置。考虑CPU需要先辨别任务类型，是计算密集型还是I/O密集型。
所以我们的线程可能处于运行中、就绪、阻塞/等待，这些状态中的一种。即我们的线程大部分时间不会在CPU上运行。
这里假设我们的CPU有一个核心，其可能同时在处理10个请求，然后10个请求都在1S后完成。
所以，使用QPS计算CPU要注意，QPS≠CPU核数。

在上面的例子中，服务器需满足峰值 7000QPS，并留有冗余（如 20%-50%）以应对突发流量。
多数的请求和发推文一样，不是存储的CPU计算，中间有等待网络、数据库、磁盘等操作。

计算公式如下：
CPU核数 = (QPS * 平均单次请求的CPU消耗时间) / 单核CPU的目标使用率。
假设平均单次请求的CPU消耗时间为0.1s，单核CPU目标使用率为70%。
那么满足7000QPS的配置为 7000 x 0.1 /0.7=1000

7000QPS需要1000核。

数据库服务器

数据库服务器主要考虑连接数与处理能力。在分布式架构中还需要考虑主从架构读写分离模式，需要将请求读写分离做计算。

处理能力（TPS）：由服务器的CPU、内存、磁盘I/O性能和数据库自身的优化水平决定。这是它的“内功”。
最大连接数（max_connections）：是数据库配置的一个参数，它规定了“最多能有多少个客户端同时连着我”。这更像是一个资源限制，防止连接过多耗尽内存。

确定总TPS和读写比例:
- 总TPS = 14,000 (假设为QPS的两倍)
- 假设读写比为 10:1 (互联网常见场景)
- 写TPS = 14,000 / 11 ≈ 1270
- 读TPS = 14,000 * 10 / 11 ≈ 12730
评估单机能力并计算所需服务器数:
- 主库（写）: 写操作通常压力最大，且由单台主库处理。假设一台高性能的数据库服务器（高主频CPU、NVMe SSD）可以稳定处理 2000 写TPS。
  - 所需主库数量: 1270 / 2000 = 0.635 -> 1 台主库 (足够)
- 从库（读）: 读操作可以通过增加从库来水平扩展。假设一台从库服务器可以处理 5000 读TPS。
  - 所需从库数量: 12730 / 5000 = 2.54 -> 3 台从库