一、吞吐压测概述：什么是吞吐压测、吞吐量的核心指标（QPS/TPS）、压测的目的与价值
1.1 吞吐压测到底是什么？
吞吐压测，说白了就是看系统在单位时间内能处理多少请求。
我刚开始做性能测试那会儿，总觉得压测就是使劲发请求，看系统会不会挂。后来踩过几次坑才明白——吞吐压测的核心不是「压垮」，而是「摸高」。你要找到系统在稳定运行的前提下，能扛住的最高并发量。
举个例子。你开了一家奶茶店，吞吐压测就是：
- 正常情况下一小时能卖多少杯？
- 排队排到门口时，出杯速度会不会下降？
- 如果突然来了100个人，会不会直接瘫痪？
放到技术场景里，吞吐压测关注的是系统在持续压力下的处理能力。它不像压力测试那样非要搞崩溃，也不像负载测试那样只盯着某个阈值。它要的是一个「稳态」——系统在长时间运行中，每秒能稳定处理多少请求。
核心定义：吞吐压测 = 在指定硬件和网络环境下，测量系统在单位时间内能成功处理的请求数量，并找到性能拐点。
1.2 吞吐量的核心指标：QPS 和 TPS
聊吞吐，绕不开两个词：QPS 和 TPS。很多新手容易搞混，我当年也迷糊过一阵子。
QPS（Queries Per Second）——每秒查询数
QPS 指的是系统每秒能响应的查询请求数量。它通常用在读多写少的场景，比如搜索引擎、商品列表页、资讯类App。
我在项目中遇到过最典型的 QPS 场景是电商大促时的商品搜索接口。用户疯狂刷新页面，后端每秒要处理成千上万次查询。这时候 QPS 就是命根子。
TPS（Transactions Per Second）——每秒事务数
TPS 指的是系统每秒能完成的事务数量。一个事务可能包含多个操作，比如下单 = 创建订单 + 扣库存 + 减余额 + 生成物流单。这4步合在一起才算一个完整事务。
嗯，这里要注意：TPS 比 QPS 更「重」。因为一个事务里可能嵌套了好几次数据库读写、远程调用、消息队列投递。你想想看，同样都是每秒1000，TPS 1000 的含金量远高于 QPS 1000。
| 指标 | 适用场景 | 典型例子 | 我个人的判断标准 |
|---|---|---|---|
| QPS | 读多写少、查询类接口 | 商品搜索、文章列表、用户信息查询 | 看响应时间是否线性增长 |
| TPS | 写多读少、事务性操作 | 下单支付、转账、注册流程 | 看事务成功率是否达标 |
避坑指南：我曾经在压测报告里把 QPS 和 TPS 混着写，被架构师当场指出来。后来我养成了一个习惯——先问清楚被测接口是「查询」还是「事务」，再决定用哪个指标。如果你拿不准，干脆两个都测，数据说话。
1.3 压测的目的与价值
为什么要做吞吐压测？我总结了三个最核心的目的：
- 摸清家底——知道系统到底能扛多少量，心里有数
- 发现瓶颈——找到拖慢系统的那个「木桶短板」
- 指导扩容——决定要不要加机器、加多少、什么时候加
我记得有一次给一个金融系统做压测，业务方说「我们预估峰值是5000 QPS」。结果一测，系统在3000 QPS 就开始报超时。后来排查发现是数据库连接池配小了。你看，如果不做压测，上线那天就是事故现场。
吞吐压测的价值，说白了就一句话：用最小的成本，提前暴露线上可能出现的性能问题。
警告：千万不要在没做过吞吐压测的情况下直接上线高并发业务。我见过太多「上线即雪崩」的案例，原因都是「觉得系统应该没问题」。性能问题不会自己消失，只会在大流量下集中爆发。
1.4 吞吐压测的知识体系
下面这张图是我自己梳理的吞吐压测知识结构，帮你快速建立全局认知：
1.5 一个简单的压测脚本示例
光说不练假把式。我习惯用 Python + requests 快速验证一个接口的吞吐能力。下面这个脚本虽然简陋，但能帮你直观理解 QPS 是怎么算出来的：
import requests
import time
import threading
url = "http://your-api.com/search"
results = []
def send_request():
start = time.time()
try:
resp = requests.get(url, timeout=5)
cost = time.time() - start
results.append({"status": resp.status_code, "cost": cost})
except Exception as e:
results.append({"status": "error", "cost": time.time() - start})
# 模拟100个并发请求
threads = []
for i in range(100):
t = threading.Thread(target=send_request)
threads.append(t)
start_time = time.time()
for t in threads:
t.start()
for t in threads:
t.join()
total_time = time.time() - start_time
success = [r for r in results if r["status"] == 200]
qps = len(success) / total_time
print(f"总耗时: {total_time:.2f}s")
print(f"成功请求: {len(success)}")
print(f"QPS: {qps:.2f}")
小提示：这个脚本只是演示原理，生产环境千万别这么用。真正的压测工具（比如 JMeter、Locust、wrk）在并发控制、连接复用、数据采集方面要成熟得多。后面章节我会手把手教你用这些工具。
1.6 本章小结
吞吐压测不是玄学，它是有章可循的工程实践。记住三个关键词：
- QPS/TPS——衡量吞吐的尺子
- 稳态——系统在持续压力下的稳定表现
- 拐点——性能开始下降的那个临界值
我做了这么多年压测，最大的体会是：没有数据就没有发言权。 别靠感觉判断系统性能，让数字说话。