一、测试背景与目标

业务场景：电商平台“星耀购物节”秒杀活动（限量1000件3C产品，单价1折）
技术挑战：

• 预估峰值流量：瞬时并发用户120万+

• 核心链路：库存校验→订单创建→支付回调→库存扣减

• 关键风险点：超卖、服务雪崩、数据库死锁

二、测试架构与工具链

三、压测场景设计（阶梯式增量模型）

graph LR
A[基线测试-20%峰值] --> B[容量探测-50%峰值]
B --> C[极限压测-100%峰值]
C --> D[破坏性测试-120%峰值]
D --> E[异常注入：网络抖动/节点宕机]

四、核心问题排查实录

4.1 库存超卖漏洞

• 现象：Redis扣减成功但DB最终扣减失败

• 根因：

  // 伪代码缺陷
  if(redis.decr(stock)>0){ // 步骤1
  if(createOrder()){ // 步骤2
  updateDB(stock); // 步骤3
  }
  }

• 解决方案：引入分布式事务（Seata AT模式）+ 数据库乐观锁

4.2 流量倾斜导致服务雪崩

• 监控告警：

  [ERROR] Gateway服务CPU使用率95%
[WARN] 订单服务线程池满拒绝请求

• 优化措施：

  1. 网关层增加请求指纹去重（布隆过滤器）

  2. 线程池动态扩容（DynamicTP框架）

  3. 热点商品本地缓存（Caffine loadingCache）

五、性能优化关键成果

六、容灾演练方案

1. 流量管控

   • 滑动窗口限流（Sentinel）+ 客户端验证码挑战

2. 降级策略

   # 配置示例
   feign:
   circuitbreaker:
   fallback:
   orderService: ForceReturnEmptyStock

3. 数据补偿

   • 基于Binlog的库存对账任务（Flink-CDC）

七、测试经验沉淀

📌 黄金法则1：缓存有效期必须大于秒杀活动时长（避免击穿）
📌 黄金法则2：前置验证（用户资格/地址有效性）与核心链路分离
📌 反模式警示：避免在压力下频繁调用select for update