TPS（Transactions Per Second，每秒事务数）和 QPS（Queries Per Second，每秒查询数）是衡量系统性能的核心指标，用于评估系统的并发处理能力与吞吐量，二者既有关联又有明确差异。本文将按照固定逻辑层层拆解，帮助读者全面理解并落地应用。

1. 是什么：核心概念界定

1.1 定义与核心内涵

指标

定义

核心内涵

关键特征

QPS

系统每秒能够处理的查询请求数量

针对无状态、单次完成的请求，聚焦“查询动作”的处理能力

1. 适用于读多写少的场景（如商品列表查询、新闻检索）2. 请求独立，无事务性要求3. 统计维度为“单次请求”

TPS

系统每秒能够处理的完整事务数量

针对有状态、包含多步操作的业务流程，聚焦“事务闭环”的处理能力

1. 适用于写操作或多步联动场景（如订单创建、用户支付）2. 一个事务通常包含多个子请求（如查库存→扣库存→生成订单）3. 统计维度为“完整业务流程”

1.2 两者的关联与区别

关联：一个TPS事务可能包含多个QPS查询，例如“创建订单”事务，会涉及“查询商品库存”“查询用户余额”2次查询，此时1个TPS对应2个QPS。

区别：QPS关注“单次请求的处理速度”，TPS关注“完整业务的处理能力”；无状态系统（如静态资源服务器）更关注QPS，有状态系统（如电商交易平台）更关注TPS。

2. 为什么需要：学习与应用的必要性

2.1 解决的核心痛点

系统容量无法量化：没有TPS/QPS指标，无法判断系统能承载多少用户并发，容易出现“双十一峰值系统崩溃”“日常低峰资源浪费”的问题。

性能瓶颈难以定位：当用户反馈“系统卡顿”时，通过TPS/QPS的变化可以快速定位瓶颈——若QPS高但TPS低，说明事务内的子查询效率低；若两者都低，说明系统整体吞吐量不足。

资源扩容缺乏依据：运维人员无法凭经验扩容服务器，通过TPS/QPS的压测数据，可以精准计算“支撑10万用户并发需要多少台服务器”。

2.2 实际应用价值

性能测试：作为压测的核心指标，验证系统是否满足业务需求（如要求订单系统TPS≥1000）。

容量规划：根据业务增长预测，提前扩容资源，避免峰值期服务降级。

架构优化：通过对比优化前后的TPS/QPS数据，验证优化效果（如数据库分库分表后，TPS提升50%）。

3. 核心工作模式：运作逻辑与关键要素

3.1 核心运作逻辑

TPS/QPS的统计本质是“单位时间内的有效请求计数”，核心逻辑为：划定统计周期→识别有效请求/事务→累加计数→计算每秒平均值。

3.2 关键要素及关联

统计周期

基础周期为1秒，也可通过“10秒内总请求数÷10”计算平均值，避免瞬时波动影响结果。

要素作用：周期越短，数据越灵敏；周期越长，数据越稳定。

有效请求/事务判定

QPS：仅统计成功返回结果的查询请求，失败请求（如超时、报错）不计入。

TPS：仅统计完成全流程闭环的事务，若事务中某一步失败（如扣库存失败），则整个事务不计入。

要素作用：确保指标反映“真实可用的处理能力”，而非无效请求的数量。

请求/事务类型

不同类型的请求对资源消耗不同（如复杂SQL查询比简单缓存查询更耗CPU），需分类统计（如“商品查询QPS”“订单创建TPS”）。

要素作用：避免“平均指标掩盖局部瓶颈”（如整体QPS高，但商品查询QPS低）。

3.3 核心机制

采样统计机制：高并发场景下，无需统计每1秒的数据，可通过“1分钟采样10次”的方式计算平均TPS/QPS，降低统计本身的资源消耗。

事务边界识别机制：通过埋点标记事务的“开始”和“结束”（如订单创建接口的入参为开始，返回成功为结束），精准界定事务范围。

4. 工作流程：完整链路与可视化图表

4.1 核心工作流程

TPS/QPS的统计流程可分为5个核心步骤，适用于绝大多数业务系统：

请求接入：用户请求通过网关进入系统（如HTTP请求、RPC调用）。

请求分类：系统识别请求类型——是单次查询（QPS统计范畴）还是多步事务（TPS统计范畴）。

事务/查询判定

若为查询请求：执行查询逻辑，判断是否成功返回，成功则计入QPS计数池。

若为事务请求：标记事务开始，执行所有子步骤（如查库存、扣库存、生成订单），判断是否全部成功，全部成功则计入TPS计数池。

周期计数：统计周期（1秒）结束时，累加计数池中的请求/事务数量，计算该秒的TPS/QPS。

结果输出：将统计结果写入监控平台（如Prometheus、Grafana），供开发/运维人员查看。

4.2 可视化流程图（Mermaid）

graph TD

A[用户请求接入] --> B[请求类型分类]

B -->|单次查询请求| C[执行查询逻辑]

B -->|多步事务请求| D[标记事务开始，执行子步骤]

C --> E{查询是否成功?}

D --> F{事务是否闭环成功?}

E -->|是| G[计入QPS计数池]

E -->|否| H[丢弃，不计入]

F -->|是| I[计入TPS计数池]

F -->|否| J[丢弃，不计入]

G & I --> K[1秒周期结束，计算TPS/QPS]

K --> L[写入监控平台，展示结果]

5. 入门实操：基于JMeter的TPS/QPS压测

5.1 准备工具

压测工具：Apache JMeter（开源免费，适用于入门）

被测系统：任选一个简单接口（如本地搭建的“用户查询接口”或“订单创建接口”）

监控工具：JMeter自带的聚合报告（无需额外安装）

5.2 实操步骤

步骤1：安装并启动JMeter

下载JMeter：Apache JMeter官网

解压后，双击bin/jmeter.bat（Windows）或bin/jmeter.sh（Linux）启动。

步骤2：编写测试脚本

创建测试计划：默认新建的“测试计划”即为根节点。

添加线程组：右键测试计划→添加→线程(用户)→线程组。

配置参数：线程数（并发用户数）= 50， Ramp-Up时间（启动50个线程的时间）= 5秒， 循环次数= 100。

添加HTTP请求（针对被测接口）

右键线程组→添加→取样器→HTTP请求。

配置参数：服务器名称或IP= 被测系统IP，端口号= 端口，请求方法= GET/POST，路径= 接口路径（如/user/query）。

添加事务控制器（仅TPS统计需要）

若被测接口是事务类（如订单创建），右键线程组→添加→逻辑控制器→事务控制器，将HTTP请求拖入该控制器内（确保统计完整事务）。

步骤3：添加监听器，统计TPS/QPS

右键线程组→添加→监听器→聚合报告。

聚合报告中的“吞吐量”指标，即为我们需要的TPS/QPS（单位：requests/sec）。

步骤4：执行压测并查看结果

点击工具栏的“启动”按钮（绿色三角形），开始压测。

压测结束后，查看聚合报告：

若为查询接口，吞吐量= QPS；

若为事务接口，吞吐量= TPS。

5.3 关键操作要点与注意事项

操作要点

事务类接口必须添加事务控制器，否则统计的是单步请求的QPS，而非完整事务的TPS。

合理设置Ramp-Up时间：若线程数100、Ramp-Up时间0秒，会瞬间产生100个并发，可能直接压垮被测系统。

注意事项

压测机性能需高于被测系统：若压测机CPU/内存不足，会导致统计的TPS/QPS偏低，无法反映真实情况。

多次压测取平均值：单次压测数据受网络波动影响，建议执行3次，取平均TPS/QPS作为最终结果。

避免在生产环境压测：压测会消耗系统资源，可能影响线上业务，建议在测试环境执行。

6. 常见问题及解决方案

问题1：TPS/QPS远低于预期目标

现象：压测结果显示TPS/QPS仅为目标值的50%，且系统资源（CPU/内存）未打满。

根因：数据库查询效率低（如无索引）、接口存在不必要的逻辑（如冗余日志）、线程池配置不合理。

解决方案

优化数据库：为高频查询字段添加索引，避免全表扫描；使用缓存（如Redis）缓存热点数据，减少数据库查询次数。

简化接口逻辑：删除冗余的日志打印、参数校验代码；合并多次数据库查询为一次。

调整线程池参数：增大核心线程数、最大线程数，避免线程等待导致的请求积压（如Tomcat线程池默认200，可调整为500）。

问题2：TPS/QPS波动幅度大（忽高忽低）

现象：相同并发下，TPS/QPS在100~500之间大幅波动，无稳定值。

根因：系统存在资源竞争（如数据库锁冲突）、网络波动、垃圾回收（GC）频繁。

解决方案

解决资源竞争：优化数据库事务隔离级别（如从Serializable调整为Read Committed），减少锁等待时间；避免长事务占用资源。

稳定网络环境：使用专线进行压测，避免共享网络带宽被其他业务占用；关闭压测机和被测系统的后台下载任务。

优化JVM参数：增大堆内存，调整GC算法（如使用G1GC代替CMS），减少Full GC的频率和时长。

问题3：QPS高但TPS低

现象：查询接口的QPS可达1000，但事务接口的TPS仅为100，两者差距过大。

根因：一个事务包含的子查询过多，或子查询效率低；事务内存在远程调用（如RPC调用第三方接口）导致延迟。

解决方案

优化事务内的子查询：合并多个子查询为一个复杂查询；将非核心子查询（如用户积分统计）异步化，不阻塞事务流程。

减少远程调用：将第三方接口的数据缓存到本地；使用异步调用代替同步调用，避免等待远程接口响应。

是否需要我为你整理TPS/QPS压测的核心参数对照表，方便你在不同业务场景下快速配置JMeter？