秒杀高并发架构：库存、限流与最终一致性实战

秒杀是电商架构能力的试金石：平时几百 QPS 的系统，活动开始瞬间涌进几十万请求，任何一处设计不当都会引发雪崩——库存超卖、数据库被打挂、正常订单也下不了。一套成熟的秒杀系统，核心思想只有一句话：让流量在到达数据库之前被层层消化。

流量漏斗：层层削峰

• 前端层：按钮置灰防重复点击、验证码/答题打散请求、静态资源 CDN 化，这一层能挡掉大部分无效流量；
• 网关层：限流（令牌桶）+ 黑名单风控 + 单用户限购校验，把机器人和高频请求拦在外面；
• 应用层：库存预热进 Redis，用 Lua 脚本原子扣减预扣库存，扣减失败直接返回"已抢完"，请求根本不碰数据库；
• 异步层：预扣成功的订单发入消息队列，下单服务按消费能力平稳处理，实现削峰填谷。

库存一致性与防超卖

Redis 预扣只是"占座"，真正的库存扣减在订单落库时完成。两层之间靠最终一致性对齐：支付超时未完成则回补 Redis 库存，消息队列消费失败则进入重试与死信处理。防超卖的铁律是"扣减动作必须原子化"——无论是 Lua 脚本还是数据库乐观锁，绝不允许"先查再减"的竞态写法。

给中小团队的务实建议

不是每场活动都需要顶级架构。日销千单的商城，做好三件事即可应对百人级秒杀：库存预热进缓存、下单接口加限流、数据库读写分离。等到单秒请求上万，再引入消息队列与独立的秒杀服务也不迟。微服务电商拆分应跟着业务压力走，而不是追潮流。

结语

秒杀架构的本质是"用分层换确定性"：每一层只解决一个问题，让到达核心的流量永远在系统承受范围之内。压测先行、预案兜底，是所有大促前的必修课。

相关阅读：云原生+无头电商为何成标配、跨境电商系统技术底座