Synthesize breakpoints across …

# 电商秒杀系统压测方案

一、压测目标

• 验证目标容量：峰值 5000 QPS 下三大核心接口（下单 / 支付 / 库存扣减）稳定可用
• 逐级加压找出各接口的失效临界点（拐点：TPS 不再增长、错误率突增、P99 延迟超标）
• 输出有效性边界报告：明确安全水位、最优容量、崩溃阈值三个边界

二、场景与模型设计

1. 接口链路比例（按真实秒杀漏斗）：

• 下单 ： 库存扣减 ： 支付 ≈ 10 : 10 : 3（支付仅对成功订单发起）
• 库存扣减前置在下单事务内或独立服务，需单独压测 + 链路压测结合

2. 压测数据准备：

• 预热 5万–10万 级别测试账号、SKU、令牌，避免缓存未命中失真
• 库存池设置多档（如 1000 / 1万 / 10万）验证超卖边界
• 参数化请求防缓存穿透，同时单独压测“热点单品”极端场景

三、阶梯加压策略

| 阶段 | 目标 QPS | 持续时间 | 目的 |

|---|---|---|---|

| 基线 | 500 | 10min | 建立性能基线 |

| 递增 | 1000→2000→3500→5000 | 每档 15–20min | 找拐点 |

| 超载 | 6000 / 8000 / 10000 | 每档 10min | 找崩溃临界点 |

| 尖刺 | 0→8000 秒级拉起 | 3–5次 | 模拟秒杀开抢 |

| 浸泡 | 5000×2–4小时 | 长稳 | 验证内存泄漏/连接堆积 |

四、观测指标

• 服务端：TPS、QPS、错误率（<0.1%达标）、P95/P99 延迟（如下单 P99 < 500ms，按业务定 SLA）
• 资源层：CPU（预警 70%）、内存、GC 频率与停顿、连接池/线程池饱和度、磁盘 IO
• 中间件：Redis（库存扣减热点 key）、MySQL（行锁等待、慢查询）、MQ 积压量
• 业务正确性：库存最终一致性对账、超卖数 = 0、订单-支付状态一致

五、失效临界点判定标准

满足任一即判定到达临界点：

1. TPS 随并发增加不再上升甚至下降

2. 错误率 > 0.5% 或出现超卖/资损类业务错误

3. P99 延迟超过 SLA 的 2 倍

4. 出现雪崩征兆：连接池耗尽、GC 风暴、级联超时

六、有效性边界报告结构

1. 安全运行区间：错误率<0.1%、延迟达标的最大稳定 QPS

2. 最优容量点：单位资源 TPS 产出最高点

3. 极限临界点：开始劣化的 QPS 与崩溃 QPS

4. 瓶颈定位：逐层归因（应用/DB/缓存/网络）+ 火焰图证据

5. 改进建议：限流阈值、扩容方案、降级预案、超卖防护加固

6. 复测验证：优化后同场景回归对比

七、注意事项

• 压测流量打标，与生产隔离或选择低峰窗口；具备一键熔断压测的开关
• 每轮压测前重置数据，结果取多轮均值，排除预热干扰
• 真实业务校验