网站关键词的布局关键词排名方法

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

引言

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

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

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

• 每秒事务数-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）：是数据库配置的一个参数，它规定了“最多能有多少个客户端同时连着我”。这更像是一个资源限制，防止连接过多耗尽内存。

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

在我们的例子中，7000QPS对应14000TPS，都是写请求。数据库服务器可以处理3500TPS，那么我们最终需要4台数据库写服务器。

内存估算

没什么好说的。
内存=(基础内存 + QPS * 内存/请求) * 冗余

估算存储需求

主要考虑存储方式与多媒体带宽。

小的结构化的数据可以使用关系型数据库如MySQL进行安全存储，保证事务和一致性。
需要支持大数据量统计的，可以使用列式存储数据库。

使用集群进行数据安全冗余。

• 存储I/O
  还是以前面的7000QPS峰值计算，每个请求带1MB文件，那么每秒要上传7000MB文件。
  一般分布式存储多节点并行写入，需要副本保障安全，实际带宽可能要 x3。