大促前全链路压测的核心目标不是“压垮系统找快感”，而是用最贴近真实流量的方式，提前暴露那些只在极端并发下才现形的接口瓶颈，你需要覆盖的全部关键接口，可以归纳为一条主线：从用户登录、浏览商品、加购下单，到支付结算、库存扣减、订单生成，再到消息通知和售后查询，每一个环节的对外接口和内部依赖接口都不能缺席。
先盘核心交易链路：下单和支付接口是压测的“主战场”
大促流量再大，最终都要落到“买家付钱、卖家发货”这两个动作上，所以全链路压测的第一优先级，永远围绕交易主链路展开。
下单接口得按“真实用户手速”来压
平时做单接口压测，大家习惯把下单接口单独拎出来，用固定参数并发怼，但大促场景下，用户行为是“先浏览、加购、再下单”，每一步都有时间差，行业共识认为，全链路压测里下单接口必须和前置的浏览、加购接口串联起来,按比例模拟用户从商品详情页到订单确认页的转化路径。
具体操作上，压测脚本里要设置思考时间（Think Time），模拟用户阅读页面、填写备注、选择优惠券的耗时，如果你直接无脑并发下单，压出来的只是接口的极限吞吐,而不是大促当天的真实体验。
支付接口要分“三路”压
支付环节的接口不只是“发起支付”这一个动作,你至少得覆盖三类接口：
- 收银台信息获取接口：用户点击“去支付”后，前端要调这个接口拉取可用支付方式、优惠信息，高并发下这个接口一旦变慢,用户会感觉整个支付流程卡住。
- 支付下单/确认接口：这是真正的支付请求入口，会调用第三方支付网关,压测时要特别关注第三方渠道的响应时长波动。
- 支付结果回调接口：支付成功后，第三方会异步通知你的系统，这个接口容易被人忽视，但恰恰是掉单问题的高发区。
多数情况下，支付结果回调接口的并发量远低于支付下单接口，但它的处理逻辑往往更重要更新订单状态、扣减库存、发消息通知，压测时应该把这三类接口放在同一个场景里，模拟“1000人同时支付，其中200人使用余额、300人用微信、500人用支付宝”的混合比例。
秒杀场景压测怎么做：独立部署和接口降级是关键
秒杀是大促压测里最特殊的一环，因为它的流量模型和常规交易完全不同，秒杀开始那一秒，QPS可能瞬间冲到日常峰值的几十倍，而且所有流量都集中在同一个商品ID上。
秒杀资格校验接口和商品详情接口要分开压
秒杀链路通常有独立的接口：抢购资格预校验、秒杀专用下单、秒杀结果查询，这些接口如果和普通商品接口混在一起压，数据互相干扰,出来的结果不具备参考性。
比较稳妥的做法是：把秒杀接口独立部署一套压测环境，单独压秒杀商品详情接口的峰值承载能力，再单独压秒杀下单接口的极限TPS，同时验证秒杀专用队列的消费速度，因为秒杀订单往往先写消息队列,再由消费者落库。
接口降级策略要在压测中“主动触发”
大促压测不应该只测正常流程，你必须设计几个故障注入场景，比如模拟商品详情缓存Redis集群宕机、模拟库存服务响应超时，这时候观察系统能不能自动切换到降级接口,降级后的响应时间是否还能撑住用户体验底线。
一位电商平台架构师在公开分享中提过：双十一前夕压测发现，购物车接口依赖的会员等级服务出现慢查询，导致购物车页面整体超时，后来把会员等级信息改成异步化获取，P95延迟直接下降了一个量级,这就是压测发现问题的典型价值。
用户链路接口：登录状态和购物车是“隐形地雷”
大促期间很多人会提前把商品加好购物车，零点一到直接下单，这意味着购物车列表接口在大促开始前10分钟就会迎来高峰,早于下单接口。
登录接口扛不住的话，后面全白搭
现在多数App登录态用Token维护，但大促时老用户Token过期重新登录的概率会明显上升，据统计，大促开始前后半小时内，登录接口的调用量会比日常高出3到5倍，压测登录接口要覆盖密码登录、验证码登录、第三方授权登录三种模式，同时关注验证码发送接口的TPS,这往往是瓶颈点。
购物车接口重在“批量查询”和“价格重算”
购物车列表接口最耗资源的不是查询商品基本信息，而是批量重算价格，每件商品的促销价、满减、优惠券分摊、会员折扣，都要在加载购物车时一次性算清，压测时建议准备多组数据：1件商品的小购物车、10件商品的中型购物车、50件商品的大购物车,按比例混合压。
营销与价格计算接口：优惠券和价格是用户投诉的重灾区
大促全链路压测里，营销接口的特点是：逻辑分支极多，参数组合爆炸，一个优惠券计算接口，可能同时涉及平台券、店铺券、品类券、新人券,每种券的使用条件和互斥规则还不一样。
优惠券模板查询接口要按热点维度压
压测优惠券接口时，不能只测“查询优惠券列表”这一个动作,要拆成：
- 可用优惠券列表接口：用户进入领券中心时调用,大促前是高频中的高频。
- 优惠券领取接口：会有明显的瞬间峰值,尤其是整点开抢的场景。
- 优惠券试算接口：用户在下单页切换优惠券时触发,大促高峰期这个接口的调用量甚至超过下单接口。
价格计算接口先把“规则命中率”跑准
价格计算接口的压测难点在于数据准备，你得构造足够多种类的商品价格模型：参与直降的商品、参与满减的商品、参与买赠的商品、不参与任何活动的商品，压测脚本里要按真实业务比例分配这些商品类型,否则压出来的接口性能数据是失真的。
库存扣减与订单生成接口：数据一致性是压测红线
库存扣减接口是全链路压测中最容易暴露分布式事务问题的地方，常见方案有基于数据库行锁的乐观锁扣减、基于Redis的预扣库存、异步消息最终一致性扣减，不同方案的适用场景差异很大,可以简单对比：
| 接口处理方案 | 适用场景 | 大促压测关注点 |
|---|---|---|
| 数据库乐观锁扣减 | 库存量少、并发可控的商品 | 关注超卖率，压测时数据库行锁竞争是否拖垮主库 |
| Redis预扣库存 | 高并发秒杀商品 | 关注Redis和数据库的库存一致性，扣减失败的回补逻辑 |
| 消息队列异步扣减 | 库存量大的常规商品 | 关注消费者处理速度，消息堆积是否会拉长订单状态变更时间 |
订单生成接口重点验证“幂等性”
大促场景下用户可能会重复点击“提交订单”按钮，如果下单接口没有做好幂等控制，会产生大量重复订单，压测时要专门设计一个场景：同一用户在同一秒内发送两次内容完全相同的下单请求，验证系统只生成一个订单，这种测试不能用常规压力机并发逻辑来处理,需要在脚本里显式构造重复请求。
订单状态流转接口要连起来看
订单从“已支付”到“已发货”，中间涉及的状态变更接口包括：支付成功回调触发订单状态更新、库存扣减确认、物流单号回写，全链路压测到最后阶段，一定要跑通“支付完成后的订单状态变更”这整条链路,确认各个接口间的消息传递没有遗漏。
基础依赖与第三方接口：先把“上下游”喂饱
全链路压测经常忽略一个事实：你的系统还依赖很多外部服务和基础组件，这些依赖一旦成为瓶颈,系统整体表现会急剧下滑。
消息推送接口、短信通知接口、App Push接口要限流压
大促时系统会自动发送大量通知：下单成功通知、支付成功通知、发货提醒，这些通知接口虽然延迟敏感度不高，但量一大就会触发第三方服务商的限流策略，压测时建议以“通知接口被第三方限流后，业务能否正常走完”为验证目标，反正大促时被限流是必然的,关键是别让通知阻塞影响主流程。
静态资源接口和网关接口同样要在压测名单里
商品详情页的图片、CSS、JS文件通常走CDN，但大促时如果配置了页面动态化渲染，网关接口的转发压力会显著上升，网关接口建议单独压一轮，确认入口层的限流阈值和熔断降级策略配置正确，网关是洪峰入口,它的QPS上限决定了你能放多少流量进来。
大促压测报告怎么写：别只贴TPS，要标出“水位线”
很多团队的压测报告只有一张TPS曲线图，这其实说明压测还没做透，一份合格的报告应该有明确的容量水位线。
从实际操作来看,报告至少需要包含以下几个维度：
- 各关键接口的TPS峰值和平均值,区分正常流量和峰值流量两种场景。
- 核心接口的响应时间分布，重点关注P95和P99，别看P50,大促场景下P50再好看也不能代表体验。
- 资源水位：各服务节点的CPU、内存、磁盘IO、网络带宽在压测期间的表现。
- 依赖接口的表现：第三方支付、短信服务、物流API的响应时间有没有明显劣化。
- 限流降级触发记录：哪个接口在什么QPS下触发了限流,系统做出了什么反应。
要记住，压测的价值不是证明系统“能扛住”，而是找出系统在什么临界点上开始变慢、报错、崩掉，把水位线标出来,运维团队在大促当天才能准确地做容量评估和优雅限流。
另一个容易被忽略的问题是压测流量的来源IP，尽量使用域名访问压测环境，真实模拟用户通过DNS解析后访问CDN、网关再到后端服务的完整网络链路，只压Service层接口而忽略网络链路层,压出来的结果会让你低估网络的延迟损耗。
大促前环境准备：测试数据、影子库、流量回放要提前做
全链路压测最怕的是什么？是压测数据污染了线上用户数据，近年来，主流互联网公司普遍使用影子表方式解决这个问题：在业务数据库里创建带特殊标识的影子表，压测产生的数据全部写入影子表,压测结束后一键清理。
压测前要先核对数据规模
全链路压测的数据量要和真实大促规模匹配，你不能用100万条商品数据去压，然后拿2000万条商品数据来评估大促风险，商品数据、用户数据、订单数据、优惠券数据,每一项都要按预估的大促规模提前准备。
流量回放是最接近真实的方式
如果条件允许，把去年大促高峰时段的真实流量保存下来，今年大促前做一次流量回放压测，这种方式能够覆盖几乎所有接口组合和用户行为路径，比人工编写压测脚本更可靠，流量回放过程中要继续使用影子表隔离写入，同时关闭非必要的消息推送,避免对真实用户产生干扰。
常见问题解答
大促全链路压测通常提前多久开始准备？
一般需要提前三到四周开始准备，第一周做接口梳理和压测脚本开发，第二周进行基准测试和调优，第三周做全链路联调预演,大促前一周进行最终验证和应急演练。
接口压测响应时间达到多少算作“通过”？
不同接口的容忍度差异较大，商品浏览类接口的P95响应时间一般建议控制在500毫秒以内，下单和支付类核心接口控制在300毫秒以内，而异步通知类接口可以放宽到2秒,具体标准需要结合你自身系统的历史基线和用户体感来定。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/774723.html
