系统设计 010：秒杀系统高并发实战

系统设计 010秒杀系统高并发实战一、高并发秒杀的核心痛点MySQL 扛不住二、基础秒杀流程Redis 挡流量MySQL 做兜底1#. 核心流程设计2#. 关键操作Redis 库存判断与扣减三、为什么必须「锁定库存」—— 防止超卖与恶意占用三种库存扣减方案对比四、并发致命缺陷非原子操作导致超卖解决方案Lua 脚本实现原子操作核心 Lua 脚本库存判断 # 扣减原子化五、超大流量终极方案MQ 削峰填谷解决方案引入消息队列MQ削峰MQ 核心作用六、用户限购Redis 集合防重复购买限购流程七、总结秒杀系统架构核心三板斧 高并发场景下流量洪峰如同海啸般袭来MySQL 数据库根本无法直面千万级请求的冲击如何在秒杀、抢购等核心业务中既保证库存精准不超卖又让系统扛住压力本文将深度拆解Redis 前置限流 # Lua 原子操作 # MQ 削峰填谷的秒杀核心架构从原理到实战一次性讲透一、高并发秒杀的核心痛点MySQL 扛不住在秒杀业务中最致命的问题就是大量请求直接打穿数据库。假设一场秒杀活动有100 万 #并发请求若所有请求都直接访问 MySQL 查询、扣减库存数据库会瞬间被压垮出现卡顿、超时、宕机甚至导致超卖、少卖等严重数据问题。✅核心解决方案用Redis做前置缓存屏障拦截 99% 的无效流量只有合规请求才会下沉到 MySQL从源头保护数据库二、基础秒杀流程Redis 挡流量MySQL 做兜底1#. 核心流程设计秒杀开始前提前将商品库存加载到 Redis 中请求优先访问 Redis 判断库存只有 Redis 校验通过才会进入数据库流程。否是用户发起秒杀请求从Redis读取库存库存 0?秒杀结束拒绝请求Redis库存 -1锁定MySQL库存创建订单用户支付MySQL库存正式扣减图表说明标准秒杀请求链路Redis 承担流量拦截MySQL 只处理有效订单请求大幅降低数据库压力。2#. 关键操作Redis 库存判断与扣减基础流程中使用两个核心 Redis 命令GET key获取商品当前库存值DECR key库存原子减 1✅性能优势Redis 单节点可支撑10 万 # QPS而 MySQL 单表仅能支撑2000#~5000 QPS用 Redis 前置拦截能把数据库压力降低90% 以上。三、为什么必须「锁定库存」—— 防止超卖与恶意占用很多开发者疑惑为什么不直接扣减 MySQL 库存非要先锁定用一个生活化案例理解水果店只剩最后 1 个苹果小明想购买但没带钱和老板约定预留 30 分钟。30 分钟内回来付款苹果归小明超时未付款苹果重新售卖。这就是库存锁定的核心逻辑下单后不直接扣减库存仅锁定库存避免用户未付款导致库存被占用设置支付超时时间15#~30 分钟超时未支付自动释放库存支付成功后再正式扣减 MySQL 库存三种库存扣减方案对比方案优点缺点适用场景下单立即扣减用户体验极佳恶意下单占用库存商品无法售卖低并发、高支付率场景支付成功扣减无库存占用无超卖下单有库存、支付无库存体验差非核心、非秒杀业务下单锁定支付扣减兼顾体验与库存安全防止超卖需实现超时释放逻辑秒杀 / 高并发核心业务主流方案四、并发致命缺陷非原子操作导致超卖基础流程中「读取库存 # 判断库存 # 0」是两步独立操作高并发下会出现严重问题库存剩余 1两个请求同时读取到库存 1两个请求都判断通过执行DECR最终库存变为 #####-1####出现超卖解决方案Lua 脚本实现原子操作Redis 2#.6# 支持Lua 脚本可将多个命令封装为原子操作要么全部执行要么全部不执行彻底杜绝并发竞争。核心 Lua 脚本库存判断 # 扣减原子化-- 获取库存keylocalstockKeyKEYS[1]-- 查询库存localstocktonumber(redis.call(GET,stockKey)or0)-- 判断库存ifstock0thenreturn-1-- 库存不足end-- 原子扣减库存redis.call(DECR,stockKey)return1-- 扣减成功✅核心价值Lua 脚本在 Redis 中单线程执行无并发冲突完美解决超卖问题性能损耗1ms。五、超大流量终极方案MQ 削峰填谷当秒杀商品数量极大如 1 万、10 万件即使 Redis 过滤后仍有上万请求瞬间打向 MySQL数据库依然会被压垮解决方案引入消息队列MQ削峰否是用户请求Lua脚本扣减Redis库存扣减成功?秒杀结束投递订单消息到MQMQ异步排队消费者按能力消费消息创建订单锁定库存图表说明MQ 作为缓冲层生产者高速投递消息消费者匀速处理避免 MySQL 被瞬时流量冲垮。MQ 核心作用削峰填谷请求先入队列消费者按 MySQL 承载能力匀速处理系统解耦秒杀服务与订单服务无强依赖一方故障不影响另一方异步处理用户无需同步等待提升响应速度✅性能提升引入 MQ 后MySQL 可稳定支撑上万订单创建无压力、无卡顿。六、用户限购Redis 集合防重复购买秒杀通常限制一人一件若用 MySQL 查询订单表校验会极大增加数据库压力。✅最优方案Redis Set 集合存储已购用户 IDSADD key userId将购买成功的用户 ID 加入集合SISMEMBER key userId判断用户是否已购买订单超时未支付用SREM key userId删除用户 ID限购流程请求进入先判断用户 ID 是否在 Redis Set 中已存在 → 直接拒绝防止重复购买不存在 → 执行库存扣减加入集合支付失败 / 订单关闭 → 从集合移除用户 ID✅优势全程无 MySQL 访问Redis Set 查询性能微秒级支撑百万级用户限购无压力。七、总结秒杀系统架构核心三板斧Redis 前置拦截扛住 99% 流量保护 MySQLLua 原子操作解决并发超卖保证库存精准MQ 削峰填谷应对超大流量平稳创建订单这套架构组合可轻松支撑百万级并发秒杀场景实现高可用、高可靠、无超卖、无压垮的核心目标是互联网高并发业务的标准解决方案