数据库设计别让库存字段成为瓶颈商品表里库存字段用int扣减时update stock stock - 1 where id ? and stock 0利用数据库行锁保证不超卖。但这条SQL在并发下会串行执行QPS上限就是单行锁的吞吐量撑死几百。所以数据库只做最终扣减不做第一道防线。订单表用唯一索引(user_id, goods_id)防止同一用户重复下单插入时捕获唯一键冲突即可。Redis预减库存把战场前移秒杀开始前把商品库存加载到Redis。用DECR命令原子递减返回值小于0说明库存不足直接拦截。这一步把绝大多数无效请求挡在数据库之外。但要注意Redis扣减成功不代表最终能下单所以需要记录一条“已扣减但未支付”的流水后续用消息队列异步落库。如果用户超时未支付再把库存加回去。消息队列削峰填谷的关键Redis扣减成功后不直接写数据库而是发一条消息到RocketMQ或Kafka。消费者端控制并发数比如开20个线程慢慢消费数据库压力就平稳了。消息里带用户ID、商品ID、扣减数量。消费失败要有重试机制重试多次仍失败则回滚Redis库存并记录异常。这样即使数据库短暂抖动也不会丢单。限流与防刷把无效流量挡在门外网关层用Sentinel或RedisLua做令牌桶限流比如每秒放行5000个请求。用户维度限流同一用户每秒最多请求一次用Redis的SETNX加过期时间实现。商品维度限流每个商品每秒放行固定数量。前端按钮点击后置灰防止重复提交。验证码是最后一道防线但会牺牲体验只在极端场景启用。分布式锁解决超卖的最后保障如果Redis集群出现故障导致扣减不准数据库层还有兜底。用Redisson的分布式锁以商品ID为key扣减前先获取锁拿到锁后再次检查库存。但锁的粒度要细只锁单个商品不要锁整个秒杀活动。锁的超时时间设短一点比如3秒避免死锁。前端优化减少无效请求静态资源全部走CDN秒杀页面提前推送到边缘节点。接口地址不要写死在页面里秒杀开始前通过Ajax获取动态URL防止被脚本提前刷。倒计时用服务器时间避免本地时间篡改。提交订单后轮询结果不要一直转圈。整体流程串起来用户点击秒杀先过网关限流再校验用户资格然后Redis预减库存。扣减成功发消息到MQ返回“排队中”。消费者从MQ取消息写订单表扣数据库库存。用户轮询订单状态成功则跳转支付。超时未支付定时任务回滚Redis和数据库库存。这套架构的核心思想是分层过滤前端挡掉重复点击网关挡掉超频请求Redis挡掉超卖MQ削平数据库压力数据库做最终一致性。每层只做自己擅长的事不要试图用一把锤子解决所有问题。SpringBoot的自动配置让我们能快速集成Redis、RocketMQ、Sentinel但集成只是开始压测和调优才是重头戏。用JMeter模拟一万并发观察各层瓶颈逐步调整线程池、连接池、超时时间才能让系统真正扛住洪峰。