一、压测基础认知：什么是高吞吐压测、为什么需要算子映射、压测的核心指标
各位同学好，我是老张。今天咱们开始聊压测，这是整个课程的地基。
很多人一上来就问我：“张哥，压测不就是拿工具怼请求吗？” 嗯，这话对了一半。如果你只是把压测当成“使劲发请求”，那你大概率会踩坑。我在项目中见过太多人，压测报告写得漂漂亮亮，一上线就崩。为什么？因为没搞懂压测的本质。
1.1 什么是高吞吐压测
先说说“高吞吐”这三个字。
普通压测，可能就几百 QPS，测测接口通不通。但高吞吐压测不一样。它要的是“在极限压力下，系统还能稳定运行”。说白了，就是把你系统往死里怼，看它什么时候扛不住。
我个人习惯把高吞吐压测分成两类：
- 容量压测：找系统的天花板。比如一个网关，到底能扛 10 万 QPS 还是 20 万？
- 稳定性压测：长时间跑，看会不会内存泄漏、连接池耗尽。我遇到过跑 12 小时，第 11 小时 59 分突然 OOM 的案例，那叫一个酸爽。
你想想看，如果连系统的极限都不知道，你怎么敢上线？
1.2 为什么需要算子映射
好，问题来了。压测的时候，你发的是 HTTP 请求，但系统内部跑的是各种算子——比如过滤、聚合、排序、窗口计算。这些算子怎么映射到压测模型上？
举个例子。你在压测一个实时风控系统。你发了一堆交易请求，但系统内部其实做了三步：
- 规则匹配（if-else 判断）
- 特征计算（用户画像、历史行为）
- 模型推理（机器学习打分）
这三步，每一步都是一个算子。如果你只压测入口，不看算子级别的瓶颈，那你根本不知道哪里慢。
核心观点：算子映射，就是把业务请求拆解成系统内部的执行单元。每个单元的性能，决定了整体吞吐。
我曾经在一个金融项目中，压测时发现 TPS 上不去。查了半天，发现是一个排序算子用了冒泡排序。嗯，你没看错，生产环境用冒泡排序。这就是算子映射没做好的后果——你根本不知道哪个环节在拖后腿。
1.3 压测的核心指标
聊指标之前，我先说一句：指标不是越多越好。很多人喜欢堆指标，什么 CPU、内存、IO、网络、GC 次数…… 但真正决定吞吐的，就四个。
1.3.1 QPS 和 TPS
这两个词经常被混用，但区别很大。
| 指标 | 全称 | 含义 | 典型场景 |
|---|---|---|---|
| QPS | Queries Per Second | 每秒查询数 | 读多写少的系统，比如搜索引擎 |
| TPS | Transactions Per Second | 每秒事务数 | 写多读少的系统，比如交易系统 |
我个人习惯这样区分：一个请求如果只读数据，算 QPS；如果涉及写库、发消息、改状态，算 TPS。你想想看，一个下单接口，既要查库存（读），又要扣库存（写），还要生成订单（写），这明显是 TPS 的范畴。
小技巧：压测时，QPS 和 TPS 要分开看。如果 QPS 高但 TPS 低，说明系统读得快写得慢，瓶颈可能在数据库或锁上。
1.3.2 延迟
延迟，就是响应时间。但这里有个坑——平均延迟不靠谱。
我见过一个系统，平均延迟 50ms，但 P99 延迟 2 秒。什么意思？99% 的请求在 50ms 内返回，但 1% 的请求要等 2 秒。如果这 1% 是核心用户的请求呢？
所以，我建议重点关注这几个分位值：
- P50：一半请求的延迟，代表一般体验
- P99：99% 请求的延迟，代表绝大多数体验
- P999：99.9% 请求的延迟，代表极端情况
嗯，这里要注意：P999 的优化成本很高，但收益可能不大。要不要优化，得看业务场景。
1.3.3 吞吐量
吞吐量，就是系统在单位时间内能处理多少请求。它和 QPS/TPS 的关系是：
吞吐量 = QPS × 请求大小（或者 TPS × 事务大小）
举个例子。一个系统 QPS 是 10 万，每个请求 1KB，那吞吐量就是 100MB/s。但如果请求变成 10KB，吞吐量就变成 1GB/s。这时候，网络带宽可能先扛不住。
避坑指南：我曾经压测一个文件上传服务，QPS 只有 2000，但吞吐量已经打满了千兆网卡。后来发现是请求体太大，网络成了瓶颈。所以，压测时一定要关注吞吐量，别只看 QPS。
1.4 知识体系总览
说了这么多，咱们用一张图来总结一下本章的核心逻辑。
这张图把本章的三个核心知识点串起来了。你仔细看：高吞吐压测是目标，算子映射是手段，核心指标是验证工具。三者缺一不可。
好了，第一章就到这里。记住一句话：压测不是怼请求，而是理解系统。下一章咱们聊聊具体的压测工具选型，我会分享一些实战中的踩坑经验。