4、压测场景设计：单接口压测、混合场景压测、阶梯加压、稳定性测试
压测场景设计，说白了就是「怎么给系统施压」的问题。很多人一上来就开搞并发，结果跑出来的数据根本没法用。我见过不少团队，压测报告写得花里胡哨，但场景设计全是拍脑袋——这其实是最要命的。
我个人习惯把场景设计分成四个维度：单接口、混合场景、阶梯加压、稳定性。咱们一个一个说。
4.1 单接口压测：先摸清每个零件的底细
单接口压测是基本功。你想想看，如果连单个接口的性能都搞不清楚，混合场景跑出来的数据你根本没法分析——到底是哪个接口拖了后腿？
我建议单接口压测至少覆盖三个维度：
- 基准测试：1个并发，跑几分钟，看基线响应时间
- 负载测试：逐步增加并发，找到拐点
- 压力测试：超过预期负载的1.5~2倍，看系统会不会崩
核心指标：TPS（每秒事务数）、平均响应时间、P99响应时间、错误率
举个例子，我曾经压过一个订单查询接口，10并发时响应时间才20ms，但到50并发直接飙到800ms。后来一查，是数据库连接池配小了。这种问题，混合场景里根本看不出来。
4.2 混合场景压测：模拟真实用户行为
单接口压测通过后，就该上混合场景了。这里有个常见的坑——很多人把混合场景做成「所有接口同时并发」，这其实不对。
真实用户的行为是有比例的。比如一个电商系统：
| 接口 | 用户行为占比 | 思考时间 |
|---|---|---|
| 商品浏览 | 60% | 3~5秒 |
| 加入购物车 | 20% | 1~2秒 |
| 下单支付 | 15% | 2~4秒 |
| 搜索 | 5% | 2~3秒 |
嗯，这里要注意：思考时间不能随便设。我见过有人把思考时间设成0，结果压出来的TPS虚高，根本不能反映真实情况。
我的经验：混合场景的脚本里，一定要加事务控制器和断言。否则你根本不知道哪个接口出了问题。
4.3 阶梯加压：找到系统的「临界点」
阶梯加压是我个人最喜欢的一种方式。为什么？因为它能告诉你系统的「软肋」在哪。
举个例子，我曾经压一个支付网关，用固定并发跑，TPS一直稳定在2000。但用阶梯加压一跑，发现并发到300时TPS突然掉到1500——原来是某个中间件的线程池满了。
阶梯加压的核心参数：
- 起始并发：建议从1开始
- 步长：每次增加10~20%
- 持续时间：每级至少跑2~3分钟
- 终止条件：错误率超过5%或响应时间超过阈值
避坑指南：我曾经犯过一个错——步长设得太大，直接从50跳到200，结果系统瞬间崩了，根本不知道是哪个并发量导致的。后来我改成每次增加20%，数据就清晰多了。
4.4 稳定性测试：看看系统能不能扛住「持久战」
稳定性测试，说白了就是「长时间跑」。很多系统短时间压测没问题，但跑个几小时就开始出幺蛾子——内存泄漏、连接池耗尽、GC频繁……这些在短压里根本发现不了。
我建议稳定性测试至少跑8小时，有条件的话跑24小时。关键看这几个指标：
- TPS趋势：是否随时间下降
- 内存使用：是否存在持续增长
- GC频率：Full GC是否越来越频繁
- 错误率：是否出现偶发性错误
记得有一次，我压一个消息推送服务，前6小时一切正常，但第7小时开始TPS缓慢下降。查了半天，发现是某个缓存没有设置过期时间，导致内存越占越多。这种问题，不跑稳定性测试根本抓不到。
4.5 四种场景的关系
这四种场景不是孤立的。我个人习惯的顺序是：
- 先跑单接口，摸清每个接口的基线
- 再跑阶梯加压，找到系统的临界点
- 然后跑混合场景，模拟真实用户
- 最后跑稳定性，验证系统能否持久运行
你想想看，如果顺序搞反了——先跑混合场景，出了问题你都不知道是哪个接口导致的，排查起来特别痛苦。
总结一下：场景设计不是越多越好，而是越「准」越好。搞清楚每个场景的目的，压出来的数据才有意义。我个人最怕看到那种「所有接口一起压，跑完看个TPS就完事」的报告——那跟没压差不多。
想要更多资料，联系可可