秒杀活动系统方法论精讲课件

SYSTEMDESIGN秒杀活动系统方法论精讲高并发·防超卖·异步削峰·工程实践2026课程导览01秒杀本质与核心挑战建立认知基准02分层架构与流量拦截逐层削峰链路03库存原子扣减与防超卖并发一致性解法04异步下单与最终一致削峰填谷闭环05生产级演进与实战工程化落地CHAPTER秒杀本质与核心挑战秒杀不是流量大一点的下单系统，而是围绕瞬时洪峰重新设计的高并发系统01秒杀与普通交易的本质差异流量流量均匀到达→瞬时爆发热点热点分散分布→极度集中于少量商品用户心智用户心智慢慢浏览→立刻响应系统目标系统目标所有请求成功→整体稳定优先一致性一致性全程强一致→核心强约束、外围最终一致三大核心挑战决定设计方向瞬时高并发挑战01流量暴增100-1000倍瞬时流量冲击系统瘫痪风险流量暴增致服务器雪崩、数据库宕机限流超卖问题挑战02库存数据不一致并发读写导致库存数据不一致直接资损订单超量即资损，订单量大于库存量库存一致性恶意请求挑战03脚本与黄牛脚本刷单、黄牛抢购抢占资源普通用户被挤掉普通用户抢不到商品风控秒杀系统设计三字诀秒杀系统，核心就三个字：快、稳、准。快流量上游拦截不打到数据库，无效请求在上游即被过滤前端限流入口处拦截无效请求，提前减负快稳层层削峰压力逐步衰减，避免瞬时冲击中间缓存扛住并发冲击，为下游减压稳准库存不多扣绝不超卖，精确扣减数据库兜底异步下单不阻塞，最终一致准核心思想是分层拦截分层限流限流解决流量洪峰请求在每一层都被拦截一部分异步削峰削峰解决瞬时压力同步操作拆成异步处理最终一致性一致性平衡性能与正确核心链路强一致、外围链路允许延迟收敛设计优先级与性能目标“秒杀系统的首要目标不是高成功率，而是守住五条底线。”这些数字是每一层技术选型的验收标准。五条底线

绝不把主站拖死隔离故障，保护核心业务

绝不出现大规模超卖库存准确是硬约束

尽可能快地给用户明确反馈秒级响应，避免长时间等待

对成功请求完成后续订单闭环扣减与下单不脱节

异常链路可补偿、可对账、可追踪失败可回溯、可修复工程验收标准：百万级QPSP99低于50ms可用性99.99%零超卖CHAPTER分层架构与流量拦截能在前端拦截的，绝不放到后端；能在缓存拦截的，绝不放到数据库02四层流水线奠定架构骨架流量承接层CDN，海量请求的入口缓冲。WAF，拦截恶意攻击流量。网关，统一路由与协议转换。静态化页面，热点数据提前降级。访问令牌，前置鉴权与防刷。入口防护请求裁剪层资格校验，先判用户是否可参与。限流，控制并发进入下游。热点隔离，独享资源防相互拖垮。库存预减，提前扣减防超卖。拦截限流事务处理层异步下单，解耦削峰提升吞吐。幂等控制，防止重复提交下单。订单落库，保证数据最终一致。支付联动，串联支付链路闭环。异步幂等治理恢复层监控，全链路指标可观测。补偿，失败事务反向冲正。对账，校验多方数据一致。回放，复现问题定位根因。熔断，快速失败防止雪崩。降级，牺牲次要保核心可用。扛得住、查得清、修得回三条拦截原则贯穿全链路设计原则：能在前端拦截的，绝不放到后端；能在缓存拦截的，绝不放到数据库；能异步处理的，绝不同步处理。前端拦截拦截按钮置灰在提交动作不可用时直接禁用，从入口阻断无效操作。防重复点击同一操作在短时间内只允许触发一次，避免重复提交。验证码把无效请求挡在浏览器端。缓存承接缓存Redis扛下绝大部分并发读与库存扣减热数据与库存操作全部在缓存层完成，响应更快。MySQL只在最终持久化时被访问数据库只承担写入落盘的职责，压力大幅降低。异步消化异步下单拆成入队与消费两段写入动作与执行动作分离，各自独立推进。用户即时拿到反馈，后端慢慢处理交互体验不受后台耗时影响，吞吐能力更强。前端层是第一道拦截屏障静态化部署2层页面纯静态HTML上CDN围观流量不触达应用服务器CDN按钮控制3层未开始置灰+服务端同步时间防篡改点击后锁定数秒同一用户一秒内限提交1–2次防重验证码分流3层滑块或简单计算题可拦截

90%

脚本流量同时削平瞬时请求尖峰90%拦截动态地址防止提前暴露入口页面与接口分离，动态地址堵死写死直连活动展示面静态承接全静态页面扛住浏览流量，稳定不动摇。交易入口面轻逻辑强保护接口短、逻辑轻，把核心交易藏在后场。动态地址一次一密按钮触发才生成秒杀地址，一次性加盐。随机延迟分散峰值前端随机延迟发请求，流量曲线变平滑。核心风险防绕过URL动态化，写死直连与验证码形同虚设。网关层用令牌桶控制总流量网关层对秒杀接口做全局限流，核心算法二选一算法一令牌桶允许短暂突发，适合容忍尖峰的业务VS算法二漏桶强制匀速输出，适合要求绝对平稳的场景20–50×放行量按库存

20到50倍配置超出请求快速失败，返回繁忙提示。宁可扼杀在网关，不冲垮下游。Nginxlimit_req_zone

按IP维度限流，单IP每秒放行数次，超过立即返回

503，形成第一道服务端防线黑名单与Token双重防护黑名单拦截恶意IP与用户直接拦截，不进入业务逻辑请求在网关层即被阻断一次性Token进入秒杀页时由后端签发请求必须携带且仅用一次频率与限购IP/用户维度频率限制同一用户同一商品限购一件缓存预热把库存提前就位库存预热到位，数据库才不在开场瞬间被击穿预热三步定时任务加载商品信息库存初始化到Redis缓存商品详情与活动规则Redis纯内存操作，微秒级响应10万QPS扛得住性能是MySQL的50到100倍MySQL磁盘10万QPS就吃力1000QPS已吃力扛10万QPS轻松监控告警预热结果纳入监控告警防止冷启动CHAPTER库存原子扣减与防超卖库存不能多扣，绝对不能超卖03超卖根因是并发读写不一致任何把读取与写入分开的方案，并发量上去后都会暴露竞态。任何把读取与写入分开的方案，并发量上去后都会暴露竞态。根因多线程并发读到相同库存值，各自扣减后写回，库存被覆盖为负。100个请求同时读到库存100，各自减1写回，最终库存大概率是99甚至98。文件锁、进程内锁在高并发写场景下扛不住。解法关键扣减动作必须原子。判断与扣减必须在一个不可分割的操作内完成。Redis加Lua实现原子扣减01检查库存读取库存判断是否小于购买数量，不满足直接返回失败原子扣减满足则执行

decrby

扣减，返回成功02实现方式预加载脚本DefaultRedisScript

预加载，调用

execute

执行原子扣减对比分两步检查与扣减收敛为一个原子动作03核心原理Lua脚本将多条命令合并为一次原子执行无中间状态，天然解决并发竞态04设计要点热点操作收敛成极少数原子动作是防超卖首选方案DECRBY的原子性保护库存DECR原子扣减01DECR原子扣减→单线程模型下天然无并发错乱，配合

EXISTS

判断库存键是否存在。02返回值判定→根据返回值决定是否回滚。返回值

≥0→扣减成功返回值

<0→执行

INCR回滚，避免库存卡在负数注意两个必须注意的细节回滚

INCR必须加，否则超卖后库存停在-1禁用GETSET模拟，它不保证先查后减的原子性收尾售罄收尾库存扣到零时设置结束标记，后续请求直接返回售罄，不再进入下单链路。四种防超卖方案各有边界数据库行锁简单可靠，适合低并发通过条件UPDATE在数据库层面保证原子性，<stock>0

条件命中才扣减库存，逻辑直接、数据一致性强，但每次更新都会占用数据库连接与锁资源，数据库压力大。悲观锁绝不超卖，几乎不用通过

SELECTFORUPDATE

将并发请求强制串行化，从源头杜绝超卖；但锁等待导致性能极差，且多行加锁易引发死锁风险，实际项目中极少采用。乐观锁性能较好，适合中低并发利用版本号机制，更新时比对版本号，不匹配则重试；无锁等待、性能较优，但高并发下冲突频繁、重试成本上升，冲突成功率低，适合中低并发场景。Redis+Lua原子脚本高并发秒杀第一选择Lua脚本在Redis中原子执行扣减与校验，性能极高、保证原子性；但整体依赖Redis的可靠性，需做好持久化与高可用保障。乐观锁与SQL级原子扣减数据库是秒杀链路最终兜底，落库仍需防超卖。—落库兜底01单条原子UPDATE→SET库存=库存-1WHERE商品ID匹配AND库存>0AND版本号匹配02去除JOIN与子查询→事务必须短，不包HTTP全程同一事务提交，保证库存与订单强一致。—一致性收束删除所有JOIN与子查询缩短事务持有时间一致性保障MySQL8.0+

原子自增版本字段InnoDB行锁+间隙锁

杜绝幻读关闭

autocommit，库存扣减与订单插入同事务提交分布式锁与热点Key防护方案选型分布式锁方案Redisson可保证扣减互斥，属通杀方案，性能略低于RedisLua脚本适合对强一致要求更高的场景可靠性锁的可靠性绝不能依赖单一Redis实例必须采用RedLock算法或Etcd等强一致性协调服务，防止脑裂导致超卖缓存防护热点Key防护Top商品构建本地Caffeine缓存+布隆过滤器前置拦截无效请求，避免单个热点Key打满Redis分片CHAPTER异步下单与最终一致能异步处理的，绝不同步处理04消息队列承担削峰填谷异步化异步处理扣减成功后不直接落库，请求信息先入消息队列，由消费者异步处理。消息队列削峰填谷削峰Redis

扛住十万级QPS

扣减瞬间，队列缓冲瞬时洪峰。填谷数据库按自身速率消化订单，不被同步请求压垮。缓冲体验优先异步反馈扣减成功先给初步反馈，最终结果异步查询，兼顾稳定与体验。异步反馈三种消息队列的技术选型兔RabbitMQ低延迟低延迟、可靠性好适用适合中小规模秒杀与结果通知链路中小规模卡Kafka高吞吐高吞吐、支持亿级消息堆积适用适合大规模流量与日志回放大规模火RocketMQ事务分布式事务支持强场景常见于电商交易场景电商从入队到落库的异步闭环链完整链路扣减Redis扣减成功→消息入队消费消费者取单→创建订单落库事务确认→双写Redis与数据库通知发送成功通知链路幂幂等控制现状消费者可能重复投递，带来重复下单风险约束靠

用户ID+商品ID

唯一约束兜底目标保证同一请求只生成一单幂等馈结果反馈询问前端轮询或WebSocket查询处理状态结论拿到明确成功或失败结果反馈强一致与最终一致的边界强强一致库存库存扣减，资损防线，零妥协库存最最终一致订单订单状态、支付结果，异步收敛，容忍短暂延迟订单事事务边界事务数据库事务只覆盖库存扣减与订单插入，不包支付与通知事务分分布式事务SeataSeata可保

ACID，但重量级协调不覆盖全链路SeataCHAPTER生产级演进与实战扛得住、查得清、修得回05服务隔离防止交叉影响隔离维度2项业务隔离秒杀接口独占线程池与资源组技术隔离热点商品单独隔离部署，避免打满全部资源配套机制2项熔断降级数据库或缓存异常时触发熔断，返回热门活动提示等降级结果接口限流Sentinel

或

Hystrix

做接口级限流，超阈值快速失败，防止服务雪崩蔓延隔离维度2项业务隔离秒杀接口独占线程池与资源组技术隔离热点商品单独隔离部署，避免打满全部资源配套机制2项熔断降级数据库或缓存异常时触发熔断，返回热门活动提示等降级结果接口限流Sentinel

或

Hystrix

做接口级限流，超阈值快速失败，防止服务雪崩蔓延防刷防作弊守护公平性防刷不是为了惩罚，而是为了保证抢购机会均等，这是秒杀系统长期运营的底线。五层拦截5层验证码/滑块：拦截脚本机器人行为校验：设备指纹识别异常模式黑名单：封禁恶意IP与用户Token一次性验证：杜绝请求重放用户频控：限制单IP每秒最多数次请求公平性保障随机延迟、排队动画、分批放行，让普通用户与脚本站在同一起跑线。防刷不是为了惩罚，而是为了保证抢购机会均等，这是秒杀系统长期运营的底线。大厂实战数据与目标基线峰值参照、目标基线、设计锚点峰值参照天猫双1154.4万笔/秒京东618100万次/秒下单流量冲击平时百倍千倍目标基线P99延迟<50ms可用性99.99%库存一致性零超卖设计锚点先定量级十万级百万级千万级决定架构复杂度与防护层数典型技术栈与分层选件接入层Nginx负载均衡接入限流应用层SpringBoot3.x应用框架缓存层RedisCluster缓存库存原子扣减异步层RocketMQ/Kafka削峰填谷治理层Sentinel限流熔断K8s编排