3. 容量压测基础：压测目的与指标（QPS/TPS/RT/错误率）、常见压测工具（JMeter/Locust/wrk）对比、压测环境搭建
3.1 压测目的与核心指标
容量压测（Load Testing / Capacity Testing）的核心目的是在非生产环境下，通过模拟真实用户负载，验证系统在预期及峰值流量下的稳定性、响应速度与资源消耗。其直接产出是系统的“容量天花板”与“瓶颈点”。
压测四大核心目的：
- 容量摸底：确定系统在可接受性能阈值内的最大并发用户数或吞吐量。
- 瓶颈定位：发现CPU、内存、数据库连接池、IO、网络带宽等资源最先达到饱和的环节。
- 稳定性验证：通过长时间（如1小时以上）持续加压，检测是否存在内存泄漏、连接未释放、GC频繁等问题。
- 弹性扩缩容基准：为K8s HPA（Horizontal Pod Autoscaler）或云服务Auto Scaling提供阈值依据。
压测结果由四个关键指标定义，缺一不可：
| 指标 | 全称 | 定义 | 典型关注值 |
|---|---|---|---|
| QPS | Queries Per Second | 服务器每秒处理的查询请求数，常用于读多写少的系统（如搜索引擎、API网关）。 | 根据业务规模，从几百到数十万不等。 |
| TPS | Transactions Per Second | 服务器每秒处理的事务数，一个事务可能包含多个请求（如下单：登录→加购物车→支付）。 | 金融、电商核心交易链路的硬性指标。 |
| RT | Response Time | 从客户端发出请求到收到完整响应的耗时，通常关注平均值、P95、P99。 | P99 < 200ms（高并发场景）；P95 < 500ms（普通Web）。 |
| 错误率 | Error Rate | 失败请求数占总请求数的百分比，包括HTTP 5xx、超时、连接拒绝等。 | 严格场景 < 0.1%；一般场景 < 1%。 |
指标关联法则：当并发数增加时，QPS/TPS会先上升至拐点（饱和点），随后下降或持平；RT和错误率在拐点后急剧上升。压测的目标就是找到这个“拐点”并确保其在业务水位之上。
3.2 常见压测工具对比
业界主流压测工具各具特色，选择时需考虑协议支持、脚本复杂度、分布式能力及资源开销。以下为三款代表性工具的横向对比：
| 特性维度 | JMeter | Locust | wrk |
|---|---|---|---|
| 开发语言 | Java（GUI + CLI） | Python（纯代码） | C（命令行） |
| 协议支持 | HTTP/HTTPS、JDBC、JMS、gRPC、FTP、TCP等（插件丰富） | HTTP/HTTPS为主，gRPC/TCP需扩展 | HTTP/HTTPS（仅支持HTTP） |
| 脚本方式 | XML（.jmx） + 插件配置 | Python代码（事件驱动） | Lua脚本（嵌入C） |
| 分布式支持 | 原生（Master-Slave） | 原生（Master-Worker） | 需自行编排（单机为主） |
| 资源开销 | 较高（JVM堆内存消耗大） | 中等（Python协程） | 极低（epoll/kqueue） |
| 实时报告 | GUI监听器 + 后端监听器（InfluxDB+Grafana） | Web UI + 导出CSV | 终端实时输出 |
| 适用场景 | 复杂业务场景、多协议、企业级全链路压测 | 持续集成、Python技术栈团队、灵活自定义 | 快速基准测试、单接口高并发摸底 |
选型避坑：
- 不要用JMeter压测极高QPS（>10万）的纯HTTP接口，其JVM本身会成为瓶颈；此时优先考虑wrk或Locust+gevent。
- Locust的Web UI在分布式模式下会收集所有Worker数据，若Worker数量超过20个，建议改用InfluxDB+Grafana方案。
- wrk仅支持HTTP/1.1，不支持HTTPS的完整握手压测（可用wrk2改进），且无法模拟登录态等复杂场景。
3.3 压测环境搭建
压测环境应独立于生产环境，但硬件规格、网络拓扑、中间件版本需与生产保持“同构”。以下是标准搭建流程：
3.3.1 环境隔离与配置清单
- 网络层：压测机与目标服务部署在同一VPC或专线内，避免公网延迟干扰；关闭压测机与目标机之间的防火墙或仅开放必要端口。
- 硬件层：压测机CPU/内存不低于目标机，避免压测机自身成为瓶颈；目标机建议使用与生产一致的实例规格（如8C16G）。
- 软件层：操作系统内核参数（如
net.ipv4.tcp_tw_reuse、net.core.somaxconn）需与生产对齐；JDK版本、GC策略、连接池配置保持一致。
3.3.2 压测机部署示例（以JMeter为例）
# 1. 下载JMeter（非GUI模式）
wget https://dlcdn.apache.org//jmeter/binaries/apache-jmeter-5.6.3.tgz
tar -xzf apache-jmeter-5.6.3.tgz -C /opt/
ln -s /opt/apache-jmeter-5.6.3 /opt/jmeter
# 2. 配置JVM参数（压测机内存较大时）
export JVM_ARGS="-Xms4g -Xmx8g -XX:MaxMetaspaceSize=512m"
# 3. 执行压测（分布式Master）
/opt/jmeter/bin/jmeter -n -t /opt/test_plan.jmx \
-R 192.168.1.10:1099,192.168.1.11:1099 \
-l /opt/results/result.jtl \
-e -o /opt/report/3.3.3 监控配套
压测期间必须同步采集目标机指标，否则无法定位瓶颈。推荐组合：
| 监控层 | 工具 | 关键指标 |
|---|---|---|
| 系统资源 | Prometheus + Node Exporter | CPU使用率、内存、磁盘IO、网络带宽 |
| JVM/应用 | JMX Exporter / Micrometer | GC次数与耗时、线程数、连接池活跃数 |
| 中间件 | Redis Exporter / MySQL Exporter | 慢查询、缓存命中率、连接数 |
| 压测结果 | InfluxDB + Grafana | QPS、RT（P50/P95/P99）、错误率 |
快速验证命令：在压测开始前，使用
wrk -t4 -c100 -d30s http://target/api/health 快速确认目标服务可达且基础响应正常，避免因环境配置错误导致压测无效。