大促前全链路压测先覆盖交易主链路、库存与优惠、支付回调、订单状态同步、搜索推荐降级、风控与限流六类接口，而不是把接口列表平均跑一遍。
大促前全链路压测要测哪些接口：先抓交易主链路
大促流量不是均匀打在每个接口上,用户从进店到支付完成，会经过商品详情、库存查询、优惠查询、创建订单、支付回调五个关键节点，全链路压测的接口选择，应该按这条动线倒推，边缘接口如签到、收藏、评论点赞，可以先做单接口验证，不必强行塞进全链路。
全链路压测和单接口压测的区别，决定接口覆盖范围
单接口压测的常见做法是拿一个接口反复加压,直到响应时间或错误率超标，全链路压测则要模拟真实用户一串连续动作，两者最大区别在于，单接口压测看不到跨服务的连接池争用、分布式锁等待、消息队列积压，大促前如果只做单接口压测，接口本身没问题，一上全链路就可能因为数据库连接数被商品查询占满，导致下单接口拿不到连接而超时，所以全链路覆盖范围必须包含串联路径上的每一环，而不是孤立地测一个下单接口。
电商大促全链路压测接口清单：按用户动线拆开看
下表按交易时序列出了必须覆盖的接口类别和压测重点。
| 链路阶段 | 关键接口 | 压测重点 | 常见瓶颈 |
|---|---|---|---|
| 商品浏览 | 商品详情、库存查询、价格查询、推荐位 | 缓存命中率、静态资源分流 | 缓存击穿、详情页DB连接占满 |
| 加购结算 | 购物车添加、优惠券列表、运费计算、结算聚合 | 并发添加、规则计算 | 购物车写放大、优惠规则CPU高 |
| 创建订单 | 下单、库存预占、优惠核销、风控校验 | 库存扣减幂等、事务超时 | 分布式锁竞争、数据库死锁 |
| 支付链路 | 收银台、支付请求、支付回调、状态查询 | 回调幂等、渠道挡板 | 回调乱序、第三方超时 |
| 订单后链路 | 订单状态同步、发货通知、售后申请 | 异步消息积压、状态机流转 | 消息重复消费、状态不一致 |
商品与库存接口：详情页挂了，后面全白搭
商品详情和库存查询是大促流量的第一道闸口,压测时先看缓存是否生效，脚本里不要每次都请求同一个SKU，要按一定比例随机打散，模拟不同商品热度，商品ID可以从CSV文件读取，每次随机取一个，避免缓存命中率虚高，库存查询接口要和下单库存预占分开压，前者可以走缓存，后者必须落库，很多团队栽在这里：只压库存查询，没压库存预占，结果下单时数据库行锁等待飙升，库存预占接口的请求体里要带上唯一requestId，数据库里建唯一索引，验证重复提交是否返回冲突。
优惠与订单接口：计算规则是大促价格体系的隐形杀手
优惠券查询、凑单计算、订单创建这三个接口，大促期间的计算复杂度会明显上升，创建订单前，系统要做一堆规则判断：是否满足满减、是否叠加、是否在有效期，压测时不能只测单一优惠场景，要准备多组用户画像：新用户、老用户、有券用户、无券用户，脚本里用参数化配置优惠券ID和商品组合，别让压测流量全部命中最简单的无优惠路径，否则真实流量一进来，规则引擎CPU先被打满，订单接口跟着超时。
支付与回调接口：资金链路必须做隔离和挡板
支付链路不建议直连真实第三方渠道,压测环境里用Mock挡板模拟支付成功、支付超时、支付失败三种返回，回调接口要重点验证幂等性：同一个订单号重复回调，只能成功处理一次，脚本里可以连续发送两次相同的回调请求，第二次应返回重复通知而不重复变更状态，订单状态查询接口要覆盖支付中、已支付、已关单三种状态轮询，很多支付问题不是下单那一刻暴露，而是回调延迟后，状态同步任务把订单改错。
大促前全链路压测数据准备：模拟真实流量比加并发更重要
压测数据如果全是临时造的,结果会骗人，测试数据量和数据分布要和真实情况接近，具体做法：
- 从生产环境脱敏拉取最近一段时间的商品和用户数据,按比例抽样
- 商品热度要符合二八分布：少量热门商品承担大多数请求
- 准备几万个测试用户和token池,每次请求随机取一个，避免同一个用户反复出现
- 优惠券数据要覆盖未使用、已使用、已过期三种状态
- 购物车数据要预置到接近真实比例的填充率
全部用同一批测试用户和同一批商品,数据库索引命中率会异常高，缓存命中率也会失真，压测结果看起来漂亮，上线后却撑不住真实流量。
大促全链路压测并发量怎么定：从历史峰值倒推
并发量不是拍脑袋定的,多数团队的做法是，把去年同一活动的峰值QPS作为基线，再结合今年业务目标上浮，行业共识认为，全链路压测的目标并发至少覆盖预计峰值的冗余量，但具体冗余比例没有统一标准，压测时不要把全部接口都设成同一个并发，要按漏斗分层：
- 商品浏览层：占全部并发的大头，模拟用户逛场
- 加购结算层：并发量约为浏览层的较小比例
- 创建订单层：再降一级，因为不是所有浏览用户都会下单
- 支付回调层：用固定速率持续打入，不追求瞬间尖峰
并发量按接口分层后，压测脚本怎么配
以JMeter为例,每个接口的线程组单独配置，商品详情用大线程组，支付回调用固定定时器控制速率，数据库连接池参数在压测前调到和生产一致，否则压测结果没有参考价值，压测脚本里必须设置断言，不能只看HTTP 200，比如下单接口要断言返回体里的订单状态为已创建，支付回调断言处理结果等于success，没有断言的压测，等于只测了网络通不通。
大促前全链路压测执行顺序：先隔离后混合
直接上全链路混合压测,出了问题很难定位，按下面顺序走：
- 第一步,单接口基线：先压商品详情、库存预占、下单、支付回调四个核心接口，各自拿到极限QPS
- 第二步,单链路串联：模拟用户从详情页到支付完成的一条完整路径，观察串联后的RT衰减
- 第三步,全链路混合：按比例同时打入浏览、加购、下单、支付流量，加入搜索和推荐接口
- 第四步,破坏性验证：手动触发缓存失效、数据库连接池缩小、消息队列延迟，看降级策略是否生效
每一步都要记录下游指标,前一步没通过，不要进入下一步。
杭州全链路压测团队怎么选：价格不是第一筛选条件
很多电商公司集中在杭州、北京、深圳，找压测团队时容易先问价格，全链路压测服务价格差异很大，按项目、按并发规模、按压测天数收费都有，报价低的团队，可能只给一份
JMeter脚本和一份聚合报告，更有价值的交付物是：链路拓扑图、瓶颈定位记录、压测前后的配置对比、改进后的复测数据，选择时可以让对方用你提供的场景先跑一轮小规模压测，看报告里有没有慢SQL、连接池等待、GC停顿这些细节，杭州本地团队的好处是现场沟通成本低，但最终还是要看报告深度。
压测后要盯住的下游指标，不只是接口成功率
接口成功率只是最外层,压测过程中要同步观察：
- 数据库连接数是否接近上限
- Redis命中率是否突然下降
- 消息队列积压量是否持续增长
- 慢SQL数量是否成倍上升
- 服务GC暂停时间是否异常
如果一个接口RT正常,但数据库连接数已经占满，说明瓶颈很快会转移到其他接口，大促前压测必须把下游指标纳入通过标准，比如下单接口的通过条件，除了成功率达标，还要满足订单表写入延迟不超过设定阈值、库存预占不产生死锁，只看接口返回200，会漏掉大量潜在风险。
大促前全链路压测的关键从来不是测了多少个接口,而是有没有把交易主链路上的串联瓶颈提前暴露，接口覆盖准、链路优先级对、下游指标盯得住，压测才算真正有效。
大促前全链路压测常见问题速答
大促前全链路压测一般提前多久做
建议至少提前两周完成首轮全链路压测,预留一周做瓶颈修复和复测，如果拖到上线前三天才发现支付回调有幂等漏洞，留给开发的时间非常紧，压测环境数据要和生产接近，否则提前多久都没用。
全链路压测工具用开源还是商业版
开源工具如JMeter、Locust、Gatling足够覆盖多数场景，成本低，脚本灵活，商业版工具在分布式压测调度、报告可视化和团队协作上更省心，选择哪种，取决于团队是否有专职压测工程师，开源工具用不好，往往不是因为工具本身，而是脚本参数和数据准备不到位。
大促前全链路压测要测哪些接口才能保证不超卖
不超卖的关键接口是库存查询、库存预占、订单创建和支付回调，库存预占必须做幂等和防重，支付回调要处理重复通知，只压库存查询不压下单价段，超卖风险依然存在，事实是，不超卖主要靠库存扣减的事务隔离和唯一约束，压测只能验证这些机制在并发下是否被击穿。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/637108.html
