3. 压测工具选型：JMeter、Locust、wrk、GoReplay对比与选择
做交易系统压测这么多年，我经常被问到同一个问题：“到底该用哪个工具？”
说实话，没有银弹。每个工具都有自己的脾气。我见过有人用JMeter测高并发，结果工具本身先挂了。也见过有人用wrk测业务接口，发现根本模拟不了真实场景。
今天我就把这四个主流工具掰开揉碎，讲讲它们的优缺点、适用场景，以及我踩过的坑。
核心观点：选工具不是选最火的，而是选最合适的。交易系统压测，核心是“真实”二字——真实流量、真实协议、真实数据。
3.1 四款工具速览
先给个全景图。我习惯用一张表来快速对比，这样心里有数。
| 工具 | 定位 | 协议支持 | 性能上限 | 学习成本 | 典型场景 |
|---|---|---|---|---|---|
| JMeter | 全功能压测平台 | HTTP、JDBC、MQ、TCP | 单机约 2000-5000 TPS | 中等 | 复杂业务场景、接口联调 |
| Locust | Python 驱动的压测框架 | HTTP、WebSocket、自定义 | 单机约 3000-8000 TPS | 低（需Python基础） | 灵活脚本、动态参数场景 |
| wrk | 轻量级HTTP压测工具 | HTTP/1.1、HTTP/2 | 单机可达 10万+ TPS | 极低 | 纯性能测试、接口基准测试 |
| GoReplay | 流量录制与回放 | HTTP、TCP（需插件） | 取决于源流量 | 低 | 线上流量回放、回归测试 |
嗯，这张表你看完应该有个大致方向了。但别急着选，咱们一个个细聊。
3.2 JMeter：老牌劲旅，但别让它背锅
JMeter 是我入行时用的第一个压测工具。说实话，它很强大，但也容易让人产生错觉。
优点：
- 图形化界面，拖拽式操作，上手快
- 插件生态丰富，支持JDBC、JMS、TCP等协议
- 有断言、监听器、聚合报告，调试方便
缺点：
- Java 写的，本身吃内存。我见过有人开1000线程，JMeter自己先OOM了
- 分布式压测配置麻烦，节点同步容易出问题
- 高并发下，GUI模式会拖慢性能
我的经验：用JMeter压交易系统，一定要用命令行模式（jmeter -n -t）。GUI只用来调试脚本。另外，记得把监听器里的“图形结果”关掉，那玩意儿最耗资源。
适合场景：接口联调、复杂业务流程（比如下单-支付-撤单）、需要断言验证的场景。
3.3 Locust：Python党的最爱
Locust 是我后来才接触的。第一次用的时候，我心想：这不就是个带Web界面的Python脚本吗？
但用久了发现，它真的很灵活。
优点：
- 用Python写压测逻辑，想怎么玩就怎么玩
- 支持动态参数、自定义协议（比如WebSocket）
- Web UI实时查看结果，分布式扩展简单
缺点：
- 单机性能不如wrk，毕竟有Python解释器开销
- 对非HTTP协议支持较弱，需要自己写Client
- 报告功能比较基础，需要二次开发
避坑指南：我曾经用Locust压一个WebSocket行情推送服务。默认的HttpUser没法用，得自己继承User类写WebSocket客户端。嗯，这个坑我踩了整整一天。
适合场景：需要灵活控制请求逻辑、动态参数、或者压测WebSocket/自定义协议的场景。
3.4 wrk：性能怪兽，但功能单一
wrk 是我做基准测试的首选。它轻量、高效，单机就能压出10万+ TPS。
优点：
- 基于C语言和epoll/kqueue，性能极高
- 支持Lua脚本，可以做一些简单的参数化
- 启动快，几秒钟就能跑完一轮
缺点：
- 只支持HTTP协议，不支持HTTPS（需要额外编译）
- 没有图形界面，结果只有命令行输出
- Lua脚本能力有限，复杂逻辑写起来很痛苦
举个例子：用wrk压一个简单的GET接口，命令就一行：wrk -t12 -c400 -d30s http://target.com/api。但如果你想模拟用户登录、带token、再发请求……嗯，Lua脚本会让你怀疑人生。
适合场景：接口基准测试、快速验证性能上限、对比不同配置下的吞吐量。
3.5 GoReplay：线上流量回放的神器
GoReplay 是我最近两年才用上的。说实话，它不算传统意义上的压测工具，更像是一个流量复制器。
优点：
- 直接从线上抓流量，回放到测试环境，真实度极高
- 支持流量放大、缩小、过滤
- 对线上服务几乎无侵入
缺点：
- 只能回放已有的流量，不能凭空创造
- 对TCP协议支持有限，需要自己写中间件
- 回放时如果依赖数据状态（比如订单号），容易出问题
我的经验：用GoReplay回放交易流量时，一定要做“数据脱敏”和“幂等处理”。我曾经回放了一笔撤单请求，结果测试环境里根本没有那笔订单，导致接口报错。后来我加了个过滤器，只回放查询类请求。
适合场景：回归测试、容量评估、线上问题复现。
3.6 如何选择？一张决策图
说了这么多，到底怎么选？我画了张图，帮你快速决策。
这张图的核心逻辑是：先看业务复杂度，再看性能需求，最后看灵活性。你想想看，如果只是测一个简单的GET接口，用JMeter就是杀鸡用牛刀。反过来，如果业务逻辑复杂，用wrk就是自讨苦吃。
3.7 我的最终建议
说了这么多，我个人的工具箱是这样的：
- 基准测试：wrk，几秒钟出结果
- 复杂业务压测：JMeter，配合命令行模式
- 灵活脚本场景：Locust，Python写起来就是快
- 线上流量回放：GoReplay，真实流量最靠谱
记住：工具只是手段，不是目的。压测的核心是发现问题，而不是跑出好看的数字。我见过太多人用wrk压出10万TPS，结果上线第一天就挂了——因为wrk压的是静态数据，而线上是动态的。
嗯，工具选型就聊到这儿。下一节咱们聊聊压测环境搭建，那又是另一门学问了。
公众号:蓝海资料掘金营，微信deep3321