过去两年，电商大促的流量峰值从每秒数万请求跃升到数十万甚至百万级。对于提供商城软件光盘、拼团软件、秒杀软件、优惠券软件和积分兑换软件的技术服务商来说，系统能否在零点那一秒稳住，直接决定了客户的GMV和品牌口碑。九二科技在多个高并发项目中积累了一些架构层面的经验，这里做一次相对硬核的拆解。

高并发下的三个典型瓶颈

秒杀和优惠券领取场景的本质矛盾在于：瞬时读请求极高、写请求集中、库存资源有限。如果不做针对性设计，系统通常会在以下环节崩塌——

• 数据库行锁竞争：同一商品库存行被数万事务同时争抢，InnoDB行锁排队直接拖垮连接池。
• 超卖与少卖：缓存与数据库状态不一致，导致库存扣减出现负数或用户领到券却无法核销。
• 热点Key击穿：单个秒杀商品的Redis Key承载几十万QPS，分片不均时单节点网卡先打满。

这些问题在拼团软件中同样存在——拼团成功瞬间的成团判定、优惠券批量发放、积分兑换的幂等处理，都会触发类似的资源竞争。

分层削峰与异步化架构

我们目前采用的方案可以概括为「前端限流 → 网关排队 → 缓存预扣 → 异步落库」四层结构。具体来说：

1. 前端通过答题、验证码、按钮置灰将无效流量削减60%以上。
2. 网关层用令牌桶做均匀排队，超出阈值的请求直接返回「活动火爆」而非超时。
3. Redis+Lua脚本完成库存原子预扣，扣减成功才生成订单令牌。
4. 订单令牌写入Kafka，由消费端异步创建数据库记录，数据库压力从数万TPS降到几千。

优惠券软件的场景略有不同，券的库存往往按批次划分，我们会在Redis中用Hash结构按batch_id分片存储，避免单一Key过热。积分兑换软件则更强调幂等，每笔兑换请求携带唯一业务流水号，消费端做去重表校验。

库存一致性如何兜底

缓存预扣解决了性能问题，但一致性需要额外保障。我们的做法是：Redis扣减成功后写入一条带过期时间的「预占记录」，异步消费落库时对比预占记录与数据库实际库存。若出现偏差，由定时对账任务在秒级内修复，并通过补偿队列重新发放或回收。这套机制在多次大促中把超卖率控制在0.01%以下。

可落地的实践建议

对于正在选型或自研秒杀软件、拼团软件的团队，几点经验值得参考：

• 压测要覆盖「缓存失效瞬间」，很多故障不是峰值本身，而是热点Key过期后大量请求穿透到数据库。
• 限流阈值动态化，根据后端RT自动调整，而不是写死一个QPS数字。
• 优惠券与积分兑换分离部署，两者虽同为营销工具，但券的读多写少和积分的写多读少特性不同，混部容易互相影响。

九二科技在商城软件光盘交付中会附带一套压测脚本和容量评估模板，帮助客户在上线前摸清系统水位。技术架构没有银弹，但把削峰、异步、对账三件事做扎实，秒杀和优惠券场景的稳定性就能从「靠运气」变成「可预期」。