Kafka吞吐压测从入门到进阶 - 第1节

一、吞吐压测入门：到底什么是吞吐压测？

各位同学好，我是老张。做了十几年性能测试，今天咱们聊聊吞吐压测。

很多人一听到「压测」两个字，就觉得是拿工具拼命发请求。其实不然。吞吐压测，说白了就是测量系统在单位时间内能处理多少请求。我习惯把它比作「高速公路的通行能力」——你修了八车道，到底能跑多少辆车？这就是吞吐量。

1.1 为什么需要吞吐压测？

我记得刚入行那会儿，有个同事上线前只做了功能测试。结果上线当天，用户一多，系统直接挂了。为什么？因为功能测试只验证「能不能用」，不验证「能扛多少人」。

吞吐压测要回答三个问题：

• 系统到底能扛多少并发？—— 峰值能力
• 在持续压力下会不会崩？—— 稳定性
• 瓶颈在哪里？—— 数据库？网络？代码？

你想想看，没有吞吐压测，就像开着一辆没装油表的车上高速——你永远不知道什么时候会抛锚。

二、吞吐量核心指标：QPS 和 TPS

聊吞吐压测，绕不开两个词：QPS 和 TPS。很多新手容易搞混，我当年也踩过这个坑。

2.1 QPS（Queries Per Second）—— 每秒查询数

QPS 指的是系统每秒能处理的查询请求数量。通常用于读多写少的场景，比如搜索引擎、商品列表页。

2.2 TPS（Transactions Per Second）—— 每秒事务数

TPS 指的是系统每秒能完成的完整事务数量。一个事务可能包含多个请求，比如「下单」这个动作，包括：查询库存 → 扣减库存 → 生成订单 → 支付回调。这一整套才算一个事务。

指标	全称	适用场景	典型例子
QPS	Queries Per Second	读多写少、查询类	搜索、列表页、详情页
TPS	Transactions Per Second	写操作、事务类	下单、支付、转账

2.3 其他关键指标

除了 QPS/TPS，还有几个指标必须关注：

• 响应时间（RT）：从发请求到收到响应的时间。一般看平均 RT 和 P99 RT。
• 并发数：同一时刻系统正在处理的请求数。
• 错误率：失败请求占总请求的比例。我一般要求 错误率 < 0.1%。

这三者之间有个经典关系：并发数 = QPS × 平均响应时间。你想想看，如果响应时间变长，并发数不变，QPS 就会下降。这就是为什么优化响应时间能直接提升吞吐量。

三、压测与常规测试的区别

很多刚入行的同学问我：「压测和功能测试有啥区别？不都是点点点吗？」

嗯，区别大了去了。我画了张图，你看一眼就明白了。

3.1 目标不同

常规测试问的是「对不对」，压测问的是「快不快、稳不稳」。我举个例子：

• 功能测试：用户登录 → 输入正确密码 → 跳转到首页 ✅
• 吞吐压测：1000 个用户同时登录 → 平均响应时间 200ms → QPS 5000 → 错误率 0% ✅

你看，功能测试只关心结果，压测关心的是在多大压力下还能保持正确结果。

3.2 压力模型不同

常规测试通常只有 1~2 个虚拟用户。而吞吐压测需要模拟真实并发场景：

维度	常规测试	吞吐压测
用户数	1~2 个	100~10000+ 个
持续时间	几分钟	数小时 ~ 数天
数据量	少量测试数据	海量真实数据
监控	基本不需要	CPU、内存、IO、网络全链路

3.3 工具链不同

常规测试用 Postman、JUnit 就够了。但吞吐压测需要专门的工具：

• JMeter：老牌工具，插件丰富，适合 HTTP/数据库压测
• Locust：基于 Python，写脚本灵活，适合自定义协议
• wrk：轻量级，适合快速压测 HTTP 接口
• Gatling：基于 Scala，性能好，适合高并发场景

我个人最常用 JMeter，因为它生态好，社区活跃。但如果你要压测 gRPC 或 WebSocket，Locust 可能更合适。

四、本章小结

好了，第一节课的内容就这些。咱们回顾一下重点：

• 吞吐压测是测量系统在单位时间内能处理多少请求
• QPS 是每秒查询数，TPS 是每秒事务数，别搞混
• 压测和常规测试的目标、压力模型、工具链完全不同

最后说一句：吞吐压测不是「跑个脚本看数字」那么简单。你得理解业务场景、设计合理的压力模型、分析瓶颈、给出优化建议。这才是真正的价值所在。