1. 吞吐测试概述与定义

1.1 到底什么是吞吐测试

吞吐测试，说白了就是看看你的系统在单位时间内能处理多少"活儿"。这个"活儿"可以是用户请求、数据库事务、文件传输量，也可以是消息队列中的任务条数。我个人习惯用一个更直白的定义：吞吐测试是测量系统在给定资源下，单位时间内能成功完成多少次业务操作的过程。

我见过不少团队，一上来就跑压测，结果跑了半天连自己在测什么都不清楚。吞吐测试的核心目标其实很明确——量化系统的处理能力。它不是要把系统打挂，也不是要看系统能抗多少人，而是回答一个最基本的问题："这套系统目前到底能处理多少？"

举个例子。几年前我在做一个电商项目，上线前老板问："这套系统能抗住双十一的流量吗？" 我当时没法直接回答，因为连系统当前的吞吐量上限都不清楚。后来我们花了大概一周，专门做了一轮吞吐测试，才把每个接口的极限摸清楚。嗯，从那以后，我每接手一个新系统，第一件事就是先跑一轮吞吐测试。

1.2 核心指标

吞吐测试绕不开几个关键指标。我建议你先把这几个概念吃透，后面做测试时才不会抓瞎。

指标	全称	含义	常用场景
QPS	Queries Per Second	每秒能处理多少查询请求	API 网关、搜索引擎、读密集型系统
TPS	Transactions Per Second	每秒能完成多少完整事务	交易系统、订单系统、支付链路
吞吐量	Throughput	单位时间处理的数据量（字节/条数）	流媒体、文件传输、消息队列
响应时间	Response Time	从发请求到收到回复的总耗时	所有系统（与吞吐量配合看）
并发数	Concurrency	同时处理的请求数量	压力测试、连接池调优

1.3 和压力测试、负载测试有啥区别

这个问题我面试时几乎必问。很多同学容易把这三个概念搅在一起。你想想看，如果连测什么、怎么测都分不清，那测试结果能靠谱吗？

测试类型	核心目标	怎么测	关心什么
吞吐测试	测量系统最大处理能力	逐步加压到资源饱和	QPS/TPS 上限、瓶颈点
压力测试	找出系统的崩溃点	持续加压直到系统失效	熔断时机、恢复能力、错误率
负载测试	评估系统在预期负载下的表现	模拟真实用户行为	响应时间、资源占用、稳定性

说白了：吞吐测试看"最多能处理多少"；压力测试看"什么时候挂"；负载测试看"在正常使用时表现如何"。三者的测试策略和数据解读方式完全不同。

1.4 为什么吞吐测试如此重要

你可能会想：系统能跑不就行了，干嘛非要知道吞吐量是多少？

原因有三：

• 容量规划的依据： 没有吞吐量数据，你拿什么做扩容决策？加几台机器、什么时候加，全凭感觉吗？我见过一个团队，线上流量翻倍后直接挂了，就是因为从来没测过吞吐量，根本不知道系统的上限在哪里。
• 瓶颈定位的起点： 吞吐量不达标时，你可以顺着链路一层层排查——是 CPU 到瓶颈了？还是数据库连接池满了？吞吐测试能帮你快速锁定短板。
• SLA 的交付证据： 客户要求系统支持 5000 QPS，你怎么证明你做到了？吞吐测试报告就是最直接的凭证。

1.5 哪些场景需要吞吐测试

几乎所有的后端系统都需要吞吐测试，但有几类场景尤其绕不开：

• 秒杀/抢购系统： 瞬时流量极高，必须提前摸清系统的 QPS 上限，否则流量一来直接雪崩。
• 流媒体/文件服务： 关注的是字节级别的吞吐量，影响到用户的播放体验和下载速度。
• API 网关/微服务： 每个接口的吞吐量都不一样，需要逐条链路做测试，否则一个慢接口会拖垮整个网关。
• 数据库/缓存层： 数据层的吞吐量往往是最先成为瓶颈的。我遇到过一次，应用层 QPS 上去了，但数据库的连接池先爆了——这就是典型的底层吞吐没测透。

1.6 避坑指南

做了这么多年吞吐测试，我踩过的坑比见过的需求还多。下面几个教训，我建议你直接保存：

• 不要一上来就跑最高负载。 我曾经图省事，直接用 1000 并发去压一个接口，结果系统直接挂了，连基础数据都没抓到。应该从低负载起步，逐步加压，记录每个节点的拐点。
• 不要忽略"预热"阶段。 JVM 需要预热、连接池需要初始化、缓存需要命中——跳过预热测出来的吞吐量，通常比实际值低 30% 以上。
• 不要只看平均值。 平均值会骗人。有一次我看到平均响应时间是 200ms，觉得很 OK，结果一查 p99 是 2 秒——系统不稳，吞吐量再高也没用。
• 测试环境要和线上尽量一致。 这个不用我多说了吧？用低配机器测出来的吞吐量，线上跑起来完全不是一回事。