1. 先回答一个问题商城为什么非要做压力测试做商城项目最怕的不是需求变而是流量一上来系统先崩。我见过不少功能全部走通的商城上线头两周一切正常等某次促销活动十点钟一开场首页接口从 200 毫秒直接飙到 5 秒下单按钮转圈半分钟最后数据库连接池被打穿订单表写入排队前端一堆报错客服消息被炸掉。这种事故一旦发生损失的不只是 GMV还有用户信任。所以商城产品的性能验证绝对不能等到线上出问题再补而是在上线前就要通过压力测试和性能监控把水位摸清楚。压力测试要做的不是简单地把并发开到很大看看会不会爆而是通过可控的、可复现的流量模型找出系统在什么压力下开始变慢、哪些组件先到瓶颈、响应时间为什么劣化、资源消耗到了什么程度最终回答三个问题当前系统能扛多少量瓶颈在哪里要支撑预期活动流量还需要做什么调整。性能监控则是压测过程中和压测之后都不可缺少的眼睛。没有监控的压测等于蒙着眼睛开车只知道车坏了不知道是哪个零件先坏的。这篇文章是商城实战系列的第 24 篇我会按自己在模拟商城项目里的真实做法从指标定义、环境准备、压测执行、监控搭建、瓶颈排查到容量评估完整走一遍并把踩过的小坑和值得复用的小经验一起放进来。适合正在做商城软件、刚接手性能优化的同学参考也适合想看明白“压测报告到底在说什么”的程序员或测试同学。2. 动手压测前先把这几个性能指标搞明白很多人一上手就开 500 线程去压压完只看“平均响应时间”没过 1 秒就觉得系统没问题。这个习惯很危险。因为没有一个指标可以单独描述系统性能尤其是平均值它会把慢请求和快请求混在一起掩盖大量尾部延迟。做商城性能评估至少要统一看六类数据。2.1 六个核心指标每一个都有独立含义第一个是 TPS/QPS。在商城场景里我习惯区分一下读操作偏多时看 QPS也就是每秒查询数写操作或完整交易链路看 TPS也就是每秒事务数。比如首页浏览、商品搜索属于 QPS下单、支付回调、库存扣减则按 TPS 评估。无论工具展示的是并发线程数还是每秒请求数压测目标必须落在这个“每秒完成数”上而不是“启动了多少线程”。第二个是响应时间但要看分布而不是平均值。平均响应时间 500ms 背后可能 99% 的请求都在 300ms 内剩下的 1% 却耗时 3 秒。商城这种场景里前端交互节奏很快1% 的慢请求就可能导致用户投诉。我一般会重点看 TP95、TP99并且把“可用性目标”建立在 TP99 上。第三个是错误率。错误率不能只看 HTTP 5xx还要看业务错误。商城里的库存不足、重复下单、支付超时都属于业务失败压力测试时如果这类比例明显升高说明系统开始拒绝正常交易这比报错更隐蔽。第四个是资源使用率。包括 CPU、内存、磁盘 IO、网络带宽以及中间件层面的数据库连接数、Redis 内存、MQ 堆积量。资源使用率的作用是帮你定位瓶颈层。比如 QPS 没上去CPU 却已经 100%那是 CPU 瓶颈QPS 上不去CPU 只有 40%但数据库连接池满了那就是连接池或 SQL 的问题。第五个是最大并发用户数。这个概念容易被误解压测工具里的并发线程数并不等于真实在线人数。一个用户从打开页面到离开会产生许多个请求而压测线程一个时刻可能只跑一个请求。商城容量预估时我通常用“活跃会话数”来做转换如果预计 5 万人同时在线其中只有 30% 的人在持续操作那核心链路的压力大约在 1.5 万活跃会话维度再结合每个会话的请求频次折算到 TPS 上。第六个是稳定性表现也就是长时间运行后的资源曲线是否平稳。很多系统短时间压测没问题泡 4 个小时就出现内存缓慢增长或者线程池因为某种异常持续占用最后突然 Full GC这个在商城场景里很常见。2.2 商城阈值怎么定一个可以抄的参考标准阈值没有绝对标准不同阶段、不同链路可以有不同的容忍度。我在模拟项目里定过一个基础框架指标阈值参考说明首屏/静态资源TP99 200ms图片、CSS、JS 等可走静态缓存商品列表/详情TP99 500ms允许依赖缓存与商品服务搜索结果TP99 800ms搜索链路相对复杂但不应超过 1 秒加购/购物车TP99 500ms写操作必须保证高成功率提交订单TP99 1s涉及库存、订单、优惠券等多服务调用支付回调TP99 2s受外部支付网关影响重点看超时与重试错误率核心链路 0.1%下单、支付不允许出现批量失败CPU 使用率压测期间 70%预留弹性与处理突增流量的余量数据库连接池使用率 80%超卖现象往往从这里开始这套阈值不是拍脑袋定的核心思路是“给线上留余量”。如果压测时 CPU 已经长期占满说明正常活动流量再叠加一些毛刺就会触发雪崩。宁可初期阈值保守一些也不要给上线埋雷。3. 压测前的装备环境、数据、脚本一个都不能省性能测试最忌讳“拿测试环境的结果直接估线上”。我曾经见过有人在低配测试机上压出 1000 QPS以为很能扛实际上测试机配置只有线上的一半数据库还是共享的旁边其他项目一跑任务立刻干扰。等到线上环境压测才发现完全不是一回事。所以在动手之前必须先把环境、数据和脚本三个装备准备好。3.1 测试环境要和线上同构至少也要成比例最理想的做法是准备一套和生产配置一致的压测环境。如果预算有限也要保证几个关键组件同构应用服务的 CPU 和内存、数据库的存储引擎与实例规格、Redis 的模式和持久化设置、消息队列的分区数量。这里的判断逻辑是性能瓶颈往往出在“最慢的那个环节”共享和不一致的环境会让压测曲线变得无意义。我建议在压测前先在环境清单里打勾是否独立网络是否避开其他项目的定时任务是否关闭监控系统自身带来的额外开销是否对压测流量做标记避免污染线上数据。真正做到位之后后续排查才会轻松。3.2 测试数据要像真实业务而不是只有一万条商城压测里见过最常见的错误是两个极端数据库表是空的或者表里只有几百条测试数据。空数据库下索引扫描和唯一键冲突的行为与真实场景完全不同几百条数据更会让 SQL 优化器错误地选择全表扫描得出偏乐观的测试结果。正确做法是从生产环境脱敏导入一份数据至少包含商城全量商品、全量类目、超过百万级订单历史、真实比例的会员账号、不同状态的优惠券和库存记录。如果出于合规无法直接导出生产数据也可以按生产分布造数。造数不是随机 insert要模拟真实的时间分布和数据倾斜。比如商品表中爆款商品只占 5%但热门详情页的访问量占 60%如果所有商品访问均匀缓存命中率就会被严重高估。压测数据一定要让热点突出来这才像真实的商城。3.3 压测脚本要按用户行为建模不能所有接口等概率访问不管用哪款开源压测工具脚本的核心是模拟业务用户的操作路径。商城不是每个接口都吃一样的流量一个典型消费者可能是这样从首页进入搜索几个关键词翻两页列表点进商品详情加购进入购物车再下单。直接对“下单接口”无脑压测测的是接口极限不是商城容量。我常用的流量比例模型是商品浏览和列表 70%搜索结果 15%加购与购物车 10%提交订单 4%支付回调 1%。不同业务阶段可以调整比如大促时秒杀接口流量突然升高可以单独压秒杀链路。脚本里还要设置合理的“思考时间”也就是用户看页面、读评价、犹豫的时间否则所有请求像机器一样打过去压力会比真实场景大好几倍。压测脚本另一个关键点是参数化。用户 ID、商品 ID、订单号不能写死否则所有请求都压在同一个数据上会人为放大数据库锁竞争和缓存热点。至少准备几万级别的用户参数池、商品参数池和优惠券参数池让压力尽量分散。4. 压力测试执行全过程从基准测试到稳定性浸泡环境、数据、脚本都准备好之后就可以开始执行了。完整的压测不是只跑一轮而是有一个递进过程。我通常把执行阶段拆成四步基准测试、负载测试、压力测试、浸泡测试。每一步都有自己的目的跳步可能导致你“知道系统会挂但不知道挂在哪个指标上”。4.1 基准测试先确定系统当前的“健康水位”第一步是用很小的并发做一次全链路冒烟比如 5 个并发跑 5 分钟。这一步的目的是验证环境可用、数据无脏数据、依赖服务都正常同时记录单并发或低并发下的 RT 基线。如果低并发时某个接口就有 3 秒延迟那后续压测没有意义先解决基础问题再说。基准测试通过后我会记录下各个核心接口在无压力情况下的 TP50、TP95、TP99以及对应资源占用作为后续所有对比的起点。很多性能问题不是开压之后才出现的而是低并发下已经能够从日志里看到连接创建耗时、序列化耗时等隐患。4.2 负载测试逐步加压找到响应时间“拐点”负载测试的目标是找到系统还能保持健康状态的临界压力。我会按阶梯式加压比如从 50 并发起步每 10 分钟提升一档依次到 100、200、400、800。每一档都保持足够长的持续时间至少 3 到 5 分钟让线程池、数据库连接池、GC 等组件充分进入稳定状态后再看数据。阶梯加压时最值得关注的是“拐点”。比如 200 并发时 TP99 稳定在 400ms400 并发时突然变成 1.2s错误率开始冒头。这个拐点就是系统健康与不健康的分界线。拐点出现后不需要继续往上加先回退一档确认系统能否恢复。能恢复说明是弹性下的性能凹坑不能恢复则说明有些组件已经发生不可逆的资源耗竭。4.3 压力测试试探系统崩溃边界负载测试是找“安全的极限”压力测试则是找“崩溃的边界”。我会在负载测试基础上继续加压加到预期峰值流量的 1.5 到 2 倍然后观察系统什么时候开始拒绝请求、哪个组件先报警、错误率如何扩散。这一步不是为了证明系统“能扛多大”而是为了确认在极端情况下系统是以什么姿势失败的。商城系统最怕的不是失败而是失败时雪崩。比如网关超时不断重试、线程池队列堆满、调用方把自己的线程也耗尽这种连锁反应比单点失败危险得多。压到崩溃边界时要看是否有保护机制生效比如限流是否触发、熔断是否打开、降级开关是否可以使用。崩溃边界最好能够快速恢复否则大促时一次故障就是长时间不可用。4.4 稳定性浸泡测试至少跑 4 小时短期压测通过不代表商城稳定我见过太多“压了半小时全绿跑 4 小时突然 OOM”的案例。浸泡测试方法很简单取压测结果中的 70% 到 80% 负载持续跑 4 到 8 小时过程中重点观察内存曲线是否一条斜线向上、Full GC 次数是否持续增加、数据库连接数是否在缓慢增长、消息队列积压是否越来越大。浸泡测试里最容易暴露的是三类问题内存泄漏、连接泄漏、临时文件或线程未释放。这些都是压力大时不明显、时间长才原形毕露的问题。特别提醒一句压测时间不要选在午后最好在很多人同时在线的工作时间之外跑或者做好监控报警别让压测流量影响其他同事的联调环境。4.5 一个关键细节如何判断系统已经“扛不住”判断压测到顶了不能只看响应时间。我总结了一个简单判据满足任意两条就可以认为是当前容量上限资源使用率持续超过 85%并且没有下降趋势错误率超过业务容忍线TP99 比基线劣化超过 3 倍某些组件出现排队比如数据库锁等待、消息队列积压持续增加、线程池拒绝任务。当然一次压测遇到这些信号不能立刻下结论需要复现一次。如果复现后表现一致就可以进入瓶颈定位环节了。5. 性能监控别等到压测挂了才去看数据压力测试和性能监控是配套的。监控的意义不仅是压测过程中看曲线更重要的是让每一次性能劣化都有数据可查。商城系统的监控至少要从四个层面采集数据少一层都会在排查问题时摸黑。5.1 监控采集要分四层系统、中间件、应用、业务系统层监控的是 CPU、内存、磁盘 IO、网络带宽、Load Average。这一层数据可以告诉我们资源是否够用但回答不了“为什么不够用”。中间件层监控数据库、Redis、MQ 等组件的关键指标比如数据库活跃连接数、慢查询数、缓存命中率、MQ 队列深度。应用层监控关注接口 QPS、RT、错误码、线程池状态、JVM 内存与 GC。业务层监控则更接近线上真实体验比如订单创建成功数、支付成功转化率、购物车异常次数。四层监控缺一不可。之前模拟项目里出现过一次诡异现象应用 CPU 不高响应时间却飙升。后来排查发现是数据库连接池被打满应用线程都在等待获取连接。如果只看应用 CPU这个问题完全看不出来必须在数据库中间件层看到连接池活跃数接近最大值才能定位。5.2 监控看板怎么搭从宏观到微观层层下钻压测前最好先搭好一个“总览到详情”的看板而不是临时在压测时拉一堆临时命令。总览页放最重要信息总 QPS、平均 RT、TP99、错误率、核心交易成功率一屏能看全。第二屏放资源层CPU、内存、磁盘、网络、数据库连接池使用率。第三屏放链路依赖Redis 命中率、MQ 积压、外部调用耗时。最后一层才是日志检索用来查具体某一次慢请求的完整调用链。看板的布局思路是“按排查顺序排列”。我从总览发现异常往下看资源层判断瓶颈方向再看中间件层确认具体位置最后看日志定位代码。这样比东一个监控西一个数字要高效得多。5.3 监控与压测联动每个峰值都要有对应记录压测执行过程中我会同步记录每个并发档位下的监控截图并且给每个请求打上压测标记方便之后日志检索。不要等到全部压完才回头看监控那样很难对得上时间点。建议在脚本里统一增加一个请求头比如“X-Perf-Test: 1”在网关层把这类流量引流到独立日志文件避免和正常联调日志混在一起。另外上线之后的性能监控同样重要。可以布置一个轻量探针任务每 5 分钟跑一次关键商品详情和下单接口的合成请求模拟真实用户访问。一但响应时间异常就能在用户大面积感知之前报警。我通常还会把压测数据保存下来和线上真实流量做对比过一段时间就能发现系统是否在劣化。6. 常见性能瓶颈与排查实录商城压测测到最后基本都会落到几个经典问题上。这里把我踩过的问题和排查思路梳理成一张实用清单方便你压测遇到同类现象时直接对照。6.1 数据库连接池被打满现象是应用 RT 突然从几百毫秒涨到几秒数据库 CPU 不高但连接池活跃连接数一直顶着最大值日志里大量“获取连接超时”。我第一次遇到时以为是数据库慢结果排查发现是一个事务里做了耗时的外部调用把数据库连接长期间占用连接池很快被耗尽。解决办法有两个方向一是把非数据库操作移出事务缩短连接占用时间二是合理调整连接池最大连接数配合慢查询治理不要盲目把连接池调大。连接池调大只是在拖延问题SQL 慢或事务长的问题不解决连接越多越容易拖垮数据库。6.2 缓存穿透、击穿与雪崩商城商品详情最依赖 Redis。缓存穿透是大量请求查询不存在的 key绕过缓存直接打数据库压测时如果参数池里有大量不存在的商品 ID就很容易看到这种情况。击穿是某个热点 key 在缓存失效的瞬间大量请求同时涌向数据库。雪崩则是大量 key 同时过期数据库瞬间被拍平。排查时看两个数据Redis 命中率是否异常下降数据库 QPS 是否在缓存失效时间点同步升高。解决思路也不复杂穿透加布隆过滤器或空值缓存击穿加互斥锁雪崩给过期时间加随机因子三个手段在商城项目里都应该直接落到代码里。6.3 慢 SQL 和索引失效压测中最常见的单点问题就是 SQL。同样一个商品列表接口测试环境数据量 10 万条时还好导入生产数据后上了百万级旧 SQL 开始全表扫描。排查方法也很固定打开数据库慢查询日志找到压测期间耗时最高的 SQL执行计划分析看是否走了索引、有没有隐式类型转换、联合索引的字段顺序是否匹配。商城订单表、库存流水表这类数据量大的表还要考虑分库分表或冷热归档。慢 SQL 不治其他所有优化都白搭。6.4 JVM 内存与频繁 Full GCJava 生态的商城容易遇到这个问题。现象是压测前期响应时间正常一段时间后突然出现周期性停顿监控里 Full GC 频繁堆内存释放后很快又占满。排查时第一个看对象占用尤其那些常驻内存的缓存是不是无界地往内存里塞第二个看有没有大对象频繁创建第三个看代码里有没有未关闭的 IO 流或网络连接。模拟项目里我们遇到过一次问题是本地缓存没有设置最大容量和过期策略并发一高缓存对象持续累积直接导致老年代爆掉。解决后 Full GC 频率明显下降TP99 也稳定了很多。6.5 线程池和消息队列积压下单链路异步化之后消息队列积压会成为新瓶颈。压测时如果订单量上升但消费速度跟不上生产速度MQ 积压持续上涨最终订单状态迟迟不更新用户侧表现为“下单后一直待支付”。排查时看一眼消费端的消费速率、消费线程数、消费方法有没有慢调用再决定是扩容消费者还是优化消费逻辑。线程池问题则表现为拒绝执行异常或者任务执行时间越来越长。建议给线程池设置合适的队列长度和拒绝策略并在压测时观察线程池活跃线程数和等待队列长度不要等拒绝异常刷屏了才发现。6.6 问题排查速查表现象优先查看常见原因RT 增长但应用 CPU 不高数据库连接池、慢查询连接占用、SQL 性能差CPU 高且 QPS 上不去CPU 热点、代码循环、GC序列化、加密、日志过多缓存命中率下降、数据库压力大Redis 命中率、 Key 失效穿透、击穿、雪崩内存曲线持续上升JVM 堆、GC、本地缓存缓存无界、资源未释放MQ 积压持续增加消费速率、消费线程消费者慢、分区不均偶发超时和错误码网关日志、外部依赖超时配置、重试风暴、熔断失效7. 压测之后容量评估与调优让结果真正有价值压测报告写完之后最容易被搁置的就是“下一步怎么办”。压测的真正价值在于指导容量规划和调优而不是留下一个“系统能扛 800 并发”的结论。在商城这类业务里我一般会把压测结果转成容量图标出每个服务实例能支撑的 TPS以及哪个实例规格对应多少预期订单量。然后给每个核心服务定一个冗余倍率比如活动预期订单峰值 3000 单/分钟核心下单服务按 2 倍峰值预留容量同时开启弹性扩容策略。调优的优先级也需要控制。别一上来就调 GC先看业务链路中哪个环节最慢。通常顺序是先解决慢 SQL 和数据库连接问题再优化缓存使用然后处理线程池和队列参数最后才到 JVM 参数和系统内核参数。因为数据库和缓存的影响面通常最大乱调 JVM 参数反而可能掩盖问题。压测不是一次性的工作。商城每次发布核心接口变更都应该重新跑一遍关键链路的负载测试。我见过很多团队上线前测一次后面半年不测等大促前再测发现系统性能已经下降了一半。合理做法是把压测纳入发布流程涉及数据库表结构变更、订单流程变更、缓存策略变更时强制要求跑一轮核心链路压测并和上一次压测报告做对比性能劣化超过 20% 就要给出解释。最后再分享一个我个人实践中的小经验压测时一定要把监控、日志、告警一起开启并且安排固定的人盯数据。压测过程里出现任何指标异常立刻截图记录而不是等到压完再回忆。性能问题定位永远依赖数据现场记录比事后复盘可靠得多。商城这种高并发场景提前一个月把压力测透好过硬着头皮在活动当天祈祷系统别挂。
