做秒杀系统这几年我踩过的坑比看过的方案多。很多文章一上来就堆架构图动辄高可用最终一致看完反而不知道怎么落地。这篇我把一个能直接落地的秒杀方案从头到尾拆一遍争取让你15分钟建立起完整的认知框架它解决了什么问题、每一层在干什么、核心环节的参数怎么定、上线之后会踩哪些坑。内容适合刚接触高并发场景的后端开发也适合想系统梳理秒杀方案的产品或架构师。我会按先理解难点、再看整体设计、然后落细节、最后讲故障复盘的顺序讲尽量不绕弯子。1. 在动手设计之前先搞清楚秒杀到底难在哪1.1 一次秒杀活动的流量画像秒杀和普通下单最大的区别不是人多而是流量在极短时间内集中爆发。假设一个日常下单接口的峰值是每秒2000次请求秒杀开启的瞬间可能直接冲到每秒20万次流量放大100倍。而且这20万请求里真正能买到商品的用户可能只有1000个也就是说99.5%的请求注定要失败。理解这个画像很重要。因为它决定了方案的核心目标不是让所有请求都成功而是在保护系统不被打挂的前提下让该成功的那批请求顺利完成并且给失败的用户一个体面的反馈。我见过很多团队把秒杀当成普通的性能优化来做加机器、扩带宽、调数据库连接池。结果活动开始后数据库还是被打爆因为流量尖峰的本质是瞬间爆发而不是持续高压。普通扩容解决的是平均水平解决不了尖峰。1.2 三个核心矛盾决定了方案走向秒杀方案的所有设计几乎都是在调和这三个矛盾第一库存有限与请求无限之间的矛盾。库存100件请求100万系统必须尽早把超出库存的流量挡在外面不能让它们一路打到库存服务和数据库。第二快与可靠之间的矛盾。用户希望秒杀结果秒出但一条订单链路涉及库存校验、订单创建、支付回调、积分变动等多个环节全同步做完必然慢。必须把链路拆成同步快速确认和异步最终完成两段。第三单点资源与分布式压力之间的矛盾。库存数据天然是单点的10万并发同时扣一个商品的库存做不好就超卖但流量又是分布式的请求会从四面八方进来。怎么让分布式系统安全地操作这个单点数据是整个方案的灵魂。这三个矛盾想清楚了后面看任何秒杀方案都会有原来如此的感觉。所谓秒杀架构本质上就是围绕这三个矛盾做取舍用异步换速度用缓存换数据库命脉用拦截换系统稳定。2. 总体架构分层拦截逐级削峰2.1 为什么必须分层而不是单点优化很多人第一反应是把数据库搞快一点。数据库再快单机能力也有物理上限而且把大量无效查询放到数据库层面等于把最珍贵的资源消耗在最没价值的事情上。正确的思路是分层拦截每一层只放行一小部分流量越靠近用户端的层越便宜、越扛压越靠近数据库的层越贵、越需要保护。我常用一个类比这就像景区限流。门口保安先拦住大部分没票的人检票口再查一次票然后按批次放人进场真正进入核心展馆的人少之又少。如果所有游客都直接涌进展馆门口验票展馆早被挤塌了。对应到技术上大概是这样的链路用户请求 → CDN静态页 → 网关限流 → 秒杀服务(本地拦截) → Redis原子扣库存 → MQ异步消息 → 订单服务 → 数据库最终落单每一层做什么、挡什么我在下面详细拆。2.2 接入层的三道闸第一道闸静态化与CDN。秒杀页面本身的HTML、CSS、JavaScript、商品图片全部提前构建成静态文件放到CDN上。用户打开页面时根本不会打到业务服务器这就化解了浏览页面这部分流量。很多团队忽略这一步结果秒杀还没开始页面接口就被刷爆了。第二道闸网关层限流。在API网关或接入层做全局限流。比如按用户维度限制每秒最多1次秒杀请求按IP维度限制每秒最多5次。限流算法我比较推荐令牌桶突发流量可以用桶里攒的令牌扛住一小波又不会无限放行。网关层限流不需要太精确它的作用是把明显异常的流量先干掉保护后端服务。第三道闸业务层的提前拦截。秒杀服务收到请求后先做几件轻量级校验活动是否在有效时间内、用户是否已经秒到过、活动状态是否正常。这几步都在内存里完成不碰数据库也不碰Redis速度极快。对不满足条件的请求直接返回未中奖或活动未开始根本不往后走。这三道闸做得好真正到达库存扣减环节的请求已经只剩原来的千分之一甚至万分之一。3. 核心环节库存扣减与下单链路3.1 库存预扣用Redis原子操作扛住高并发秒杀方案里最关键的一步是库存扣减。这里必须先用Redis扛不能直接操作数据库。原因有两方面一是Redis单机能扛每秒10万量级的读写而数据库单库能稳定扛的写操作往往只有每秒几千二是扣库存是一个读改写操作在数据库里用事务也能做但连接数会迅速打满在高并发场景下数据库很快就成为瓶颈。用Redis做扣减核心代码就是一个Lua脚本保证原子性local stock tonumber(redis.call(GET, KEYS[1])) if stock and stock 0 then redis.call(DECRBY, KEYS[1], 1) return 1 end return 0这段脚本的意思是读取库存如果大于0就减1并返回成功否则返回失败。Lua脚本在Redis中是原子执行的多个并发请求不会互相穿插所以不会出现两个请求同时读到库存为1然后都减成了0的问题。这就是防超卖的第一道防线。在执行扣减之前还有一步我强烈建议要做在秒杀服务的内存里预加载库存并进行本地预扣。比如每台机器启动时从Redis加载一次库存到本地内存请求进来先扣本地内存的计数扣成功了才去请求Redis。这样一来大部分请求在服务进程内就被拦截掉了Redis的压力又降一个量级。提示本地预扣一定要设置合理的阈值和同步机制。比如本地剩余库存达到设定水位线比如总量的20%时主动请求Redis做一次批量同步避免本地计数和Redis库存漂移过大。3.2 扣减成功之后怎么防止用户重复下单库存扣减成功后用户会进入待创建订单的中间状态。这时候你必须处理一个问题用户手快连着点了好几次或者脚本并发提交了多个请求。常规做法是令牌机制用户进入秒杀页面时服务端生成一个一次性令牌Token每次真正提交秒杀请求时必须携带这个令牌。令牌在第一次扣库存成功后立即作废后面的请求就算通过了限流也会因为令牌无效被拦截。数据库层面也要做好幂等控制。给订单表加唯一约束用用户ID 活动ID 场次ID作为唯一键或者用一个全局唯一的订单号。这样即使消息队列重复投递、下游重复消费也不会创建出两条订单。关于库存预扣和令牌还有一个细节容易被忽略预扣的库存必须有超时释放机制。用户扣减了库存但最终没有完成支付如果这批库存永远锁着活动结束后大量库存被浪费。常见的做法是给Redis里的扣减记录加TTL比如15分钟未支付自动释放同时在订单服务里做定时任务扫描超时未支付订单回补库存。3.3 异步下单把重活放到队列里慢慢干库存扣减完成只是说明用户抢到了资格真正的订单创建还在后面。这里必须把同步链路切开秒杀服务把用户已抢到资格的消息发到消息队列立即向用户返回秒杀成功然后由订单服务异步消费消息创建订单。为什么不能同步创建订单因为创建订单涉及数据库写入高并发下数据库连接池会被瞬间占满。而且订单创建后通常还要通知积分服务、优惠券服务等这些如果全部同步执行接口响应时间会恶性膨胀。用消息队列之后消费者是按自身处理能力拉取消息的相当于给数据库前面的流量装了一个缓冲池。积压的消息慢慢消化数据库始终在自己能承受的负载范围内运行。这里有一个坑我必须提醒消费者消费速度和生产者生产速度如果长期失衡消息会大量积压。解决问题不能只靠加大消费线程要先确认下游数据库是否有慢SQL、锁等待等问题。我遇到过几次消息积压最后都不是消费能力不够而是订单表缺索引导致insert越来越慢。4. 实操中的参数选择与配置要点4.1 限流阈值怎么定很多团队在限流参数上拍脑袋导致活动还没开始就把正常用户挡在外面或者限了个寂寞。我的经验是先做压测再定参数。压测结果会告诉你在保证接口99线在200毫秒以内的前提下单机每秒能扛多少请求。假设单机压测上限是每秒5000请求你有20台秒杀服务那网关层的总限流可以设为每秒10万留出一倍余量。业务层的用户维度限流则参考正常用户手速上限来定一个人每秒最多点5次就很高了超过这个值基本可以判定为异常。限流参数还要做全局限流与单机限流配合。全局限流放在网关保护整体容量单机限流放在应用层防止某一台机器因为流量不均匀被单独打挂。4.2 Redis库存分片的取舍Redis单机虽然快但面对极端流量还是有压力。于是有人提出把库存分片到多个Redis key上比如把100件库存分成10个key每个key放10件请求随机路由到其中一个key扣减。这个方案能提升吞吐但有一个代价会引入部分超卖风险。每个key各扣各的最后汇总实际扣减数可能大于总库存。解决的办法是库存总数按key均分后每个key多放一点冗余比如每个key放11件活动结束后回收冗余部分。但对大部分业务场景我觉得没必要这么激进。单机Redis配合Lua脚本每秒扛几万次扣减完全够用先把架构做简单再根据压测结果决定要不要分片。注意无论是分片还是不分片库存记录和用户秒杀成功的记录一定要放在同一个Redis实例的同一个Lua脚本里完成才能保证扣了库存和记住了用户同时成功或同时失败。一旦这两个操作分离就会出现库存扣了但用户没记录或者相反的情况。4.3 消息队列的选型与参数消息队列我建议用吞吐能力强的成熟产品。秒杀场景的特点是消息量瞬间巨大但每条消息很小、处理逻辑相对简单所以选型时重点看吞吐和堆积能力不用追求过于复杂的事务消息。生产端要注意批量发送。秒杀期间逐条发送消息发送本身的性能开销会被放大。我在实践中通常是攒够50条或者10毫秒的时间窗口批量发一次吞吐能提升好几倍。消费端要设置合理的并发数和重试策略。消费失败先重试几次重试仍失败就进入死信队列人工处理不要无限重试阻塞后续消息。5. 上线后一定会遇到的故障与排查实录5.1 库存超卖现象与根因超卖是秒杀系统最典型的故障。表象是订单数大于库存数但根因往往不止一个。最常见的原因是扣减和订单创建不同步。比如Redis扣减成功了但订单服务消费消息时重复创建了订单而订单数量和Redis扣减数量不一致。第二种是本地预扣与Redis同步没做好本地扣多了Redis实际库存被扣成负数。排查超卖问题我有一套固定的流程先导出所有成功订单的用户清单去Redis里对比秒杀成功记录再导出Redis扣减记录和数据库最终库存看两者是否一致。哪个环节对不上问题就在哪。这套流程我建议你在压测阶段就做一遍不要等线上出事故再临时追查。5.2 缓存雪崩与击穿秒杀场景下所有库存都在Redis里如果Redis里的库存key在活动进行中过期缓存就相当于被击穿了——所有请求瞬间压到数据库一场秒杀直接变成数据库灾难点。预防措施两个一是库存key不要设过期时间活动生命周期内用硬编码TTL管理活动结束后主动删除二是即使要设过期时间也要加随机偏移量避免大量key同时过期。还有一个是缓存穿透用户反复请求一个不存在的商品ID每次都会穿透到数据库。秒杀场景更常见的是秒杀失败的用户反复重试这些人虽然没有库存可扣但请求依然可能打到后端。建议在网关层针对已秒杀失败的用户做短期标记比如10秒内不再放行同一用户的重复请求。5.3 热点数据与单机瓶颈活动期间某些爆款商品的库存key访问量会特别高单个Redis实例可能出现CPU飙高。如果压测发现单实例确实扛不住分片方案才真正派上用场按商品维度拆分库存key再在前端做一致性哈希路由。但我还是建议先通过分层拦截把流量压下去很多时候不是Redis扛不住而是前面的拦截做得不够狠。另外我踩过一个坑秒杀服务的日志打印在活动期间把磁盘IO打满了。高并发下每条请求打一条info日志日志量会大得吓人。秒杀期间要把日志级别调到WARN以上只记录异常和关键状态变化否则系统不是被流量打挂的是被自己的日志打挂的。5.4 活动结束后对账怎么快速做秒杀结束不等于事情结束。我习惯在活动结束后跑一套对账脚本核对三组数据Redis扣减总数、订单创建总数、实际支付成功总数。三者关系应该是支付成功数 ≤ 订单创建数 Redis扣减成功数考虑超时未支付释放的影响。对账发现差异并不可怕关键在于能不能定位到具体订单。所以从设计的第一天起所有环节都要带上全局唯一的请求链路ID从用户请求、Redis扣减、MQ消息到订单记录全程透传。没有这个ID出问题之后排查成本会高到让你怀疑人生。我在实际维护秒杀系统的过程中最大的体会就是秒杀方案本身并不神秘无非是提前拦截、异步削峰、原子扣减、最终对账这四件事。但把这四件事做到位需要你对每一层的边界和参数有清晰的认知。回到开头说的三个矛盾只要时刻记得库存有限、请求无限快与可靠的取舍单点数据与分布式的博弈你设计的方案就不会跑偏。最后分享一个我一直在用的小技巧每次秒杀活动结束别急着清理所有数据。把当时的流量曲线、限流触发次数、Redis峰值QPS、消息积压深度完整保存下来作为下一次活动的压测基线。做得多了你就能总结出自己业务特有的流量模型到那时候设计秒杀方案对你来说就不是什么难事了。