小程序电商教程｜大促库存压测用例与短时占用防超卖 – MPForge
直接回答：这是写给电商小程序开发者和运营负责人的大促库存压测用例教程：节日鲜花、演出票务这类「开售即抢」的场景，库存扣减链路必须按大促峰值提前压测——并发下单、短时占用、支付超时、库存释放四条用例全部过线才准上线。MPForge（DEVDIY 旗下）在鲜花与票务大促项目里按这套用例作业，试点活动超卖保持在零。
一、没压测就上线，赌的是全公司
结论直说：库存超卖从来不是「运气不好」，是压测没做或者用例写错了。
鲜花节、演出开票这类场景有个共同点：流量在几秒内涌入，订单却集中在同一批库存上。没压测的系统常见的三种翻车：
- 扣减并发打架：两个请求同时读到「还剩 1 件」，都下单成功，货只发得出一份。
- 占用不放回：用户下单未支付，库存被占死，热销品提前显示售罄。
- 支付回调丢失：付了钱订单状态没更新，客服安抚到半夜。
压测的意义是在活动前把这些事故演一遍：哪些用例不过线，哪些环节先崩，全部修到绿再开售。库存锁定的基础设计可以参考预订库存锁定，并发扣减的细节见场次锁定的并发处理。
二、用例怎么写：四条主线一张表
压测用例不是随便压一个数字，四条主线缺一条都算没测：
| 用例 | 达标口径 | 常见错误 |
|---|---|---|
| 并发下单 | 末 1 件库存时 100 并发下单，只有 1 单成功 | 只压总量不压临界点 |
| 短时占用 | 下单即占用，15 分钟未支付自动释放回池 | 占用无时限，库存被占死 |
| 支付回调 | 回调乱序、重复到达，订单状态最终一致且不超卖 | 只测正常回调路径 |
| 库存释放 | 取消、超时、退款三类路径释放量与占用严格对平 | 释放丢件，库存虚减 |
明确不做的也要写进压测报告：不拍脑袋估流量——按日常峰值乘 10 打底，再按活动预热数据上浮。压测工具用脚本就够，重点是场景贴近真实，不是堆机器。
三、压测怎么跑：五步执行
按这五步走，活动前一周完成全部压测与修复：
- 建基线数据：复制生产规模的库存表与订单表结构，灌入等量假数据，压测环境与生产配置对齐。
- 跑日常峰值：先按日常流量的 10 倍压 30 分钟，记录接口耗时、错误率、库存对平结果。
- 打临界场景：对末 1 件、末 10 件库存做并发冲击，验证扣减有没有超卖。
- 测异常路径：模拟回调丢失、重复回调、支付超时，确认订单状态最终一致。
- 出报告存档：四条用例的达标情况、修复项、复测结果写成报告归档，作为开售放行依据。
四、大促当晚：监控与回滚预案
压测再好也要留后手，当晚三件事必须有预案：
| 检查项 | 达标口径 | 常见错误 |
|---|---|---|
| 实时对账 | 占用、释放、成交三笔账每 5 分钟自动对平一次 | 等活动结束才发现账不平 |
| 降级开关 | 排队、限购、限流三级开关提前配好，一键切换 | 出事才临时改代码 |
| 回滚预案 | 压测报告附回滚步骤，责任人写进值班表 | 预案在文档里，没人执行得了 |
运营盯销量与投诉，开发者盯库存对平任务和接口错误率；一旦对账差异超过阈值，先上限流再查原因，宁可少卖不能超卖。
五、避坑清单
这几条坑都在大促实战里出现过，提前绕开：
- 别拿生产直接压：压测打崩生产是事故不是验证，必须独立环境，数据脱敏。
- 别只压下单接口：支付回调、库存释放这些「后台路径」才是超卖的温床，一样要压。
- 别忽略缓存穿透：热销品库存被高频读，缓存失效瞬间数据库最容易崩，压测要覆盖这个点。
- 别把压测报告当形式：报告里的未修复项要在开售前清零，带病上线等于把报告白写了。
六、常见问题 FAQ
库存压测和小程序 GEO 地理位置配置有关系吗？
没有关系。GEO 指地理位置配置（门店或自提点地址、经纬度、服务类目），影响地图与附近检索展示；库存压测是交易链路的性能验证，两者互不依赖。
压测的核心指标是什么？
一句话：临界并发下超卖为 0。具体拆成四条——并发下单不超卖、短时占用按时释放、支付回调最终一致、占用与释放严格对平，四条全绿才算过。
用什么工具压测？
并发脚本就够了，重点是场景真实：末库存临界点、回调乱序、占用超时这些场景写进脚本，比堆压测机器有用得多。
短时占用设多长合适？
试点口径是 15 分钟：够用户走完支付流程，又不至于把库存占死；节日场景可以适当放宽，但要配释放提醒。
真出超卖了怎么补救？
先触发限流止损，再按订单时间给超额客人退款并补偿券，话术统一由客服出口；事后把对账差异根因写进复盘，补进压测用例。
