首先，我们先了解高并发秒杀系统，什么是高并发秒杀系统？
要真正认识高并发秒杀系统，不能只停留在“减库存+下单”的代码层面，而应从业务特性、技术挑战、架构设计和工程实践 四个维度系统理解。
一、什么是高并发秒杀系统？——核心特征
定义：在极短时间内（如1秒），大量用户（数万至百万级）同时抢购有限数量商品的高压力场景。
典型特征（“三高一短”）：
1.高并发：瞬时QPS可达10w+,远超日常流量。
2.高竞争：商品库存极少（如100件），大量请求注定失败。
3.高一致性要求：不允许超卖（库存为负）和重复下单。
4.时间窗口极短：秒杀活动通常只开放几秒到几分钟。
总结：用有限资源服务海量请求，且必须保证公平性与数据正确性。
二、核心挑战 （为什么难？）
1.性能瓶颈
如果数据库扛不住高并发读写，可能会导致DB连接池耗尽、响应超时。
2.超卖问题
多线程/多服务同时扣库存，可能导致库存变负，商家亏损。
3.系统雪崩
某服务崩溃引发连锁反应，可能导致整个系统不可用。
4.用户体验差
页面卡顿、按钮点不动，导致用户流失、口碑受损。
5.安全风险
出现脚本刷单、机器人抢购，真实用户抢不到。
三、关键技术栈与解决方案（分层应对）
高并发秒杀系统的设计哲学：“层层过滤、异步解耦、缓存前置、最终一致”。
1.前端层：减少无效请求
。静态化页面：秒杀页提前生成HTML、CDN缓存，避免动态渲染
。按钮置灰+倒计时：未到时间禁止点击
。验证码/行为验证：防机器人（如滑块、点选）
。本地缓存库存状态：避免频繁查后端
2.网关层：流量控制第一道防线
。限流：Nginx+Lua/Sentinel,按IP或用户ID限流（如1次请求每秒)
。熔断降级：秒杀服务异常时返回友好提示，不拖垮主站
。黑白名单：封禁恶意IP
3.服务层：核心逻辑优化
（1）库存预扣（最关键！）
。Redis预热库存：活动开始前将库存加载到Redis(如 stock:1001=100)
。Lua 脚本原子操作：
local stock=redis.call('GET',KEYS[1])
if tonumber(stock)>0 then
return redis.call('DECR',KEYS[1])
end
return -1
——> 保证 查+减 原子性，彻底解决超卖
(2)防重复下单
。分布式锁+唯一索引：
redis锁：seckill:user:{userId}:goods:{goodsId}
DB唯一索引：(user_id,goods_id)防止多次插入订单
(3)异步下单（削峰填谷）
。秒杀成功->发消息到MQ(如RocketMQ/Kafka)
。消费者异步创建订单、扣DB库存、发短信等
优点：DB压力从10w QPS 降至几千，系统更稳
4.数据层：保障最终一致性
（1）数据库优化：
。库存字段加 行级锁 或 乐观锁（version字段）
。订单表 分库分表（按user_id哈希）
。热点商品单独分表
（2）缓存一致性:
。秒杀结束后，通过Binlog(Cannal)或定时任务同步Redis与DB库存
5.监控与运维
（1）全链路追踪：SkyWalking/Zipkin,定位慢接口
（2）实时监控：Prometheus+Grafana(QPS、延迟、错误率）
(3) 压测验证：JMeter模拟 10w并发，验证系统水位
四、典型架构图（简化版）
用户
↓
CDN（静态页）
↓
Nginx（限流/负载均衡）
↓
Spring Cloud Gateway（鉴权/路由）
↓
Seckill Service（Redis 扣库存 + 发 MQ）
↓
RabbitMQ / RocketMQ
↓
Order Service ←→ Inventory Service ←→ Points Service
↓ ↓ ↓
MySQL MySQL MySQL
关键思想：把99%的流量挡在数据库之外！
五、如何深入理解？——三个认知层次
层次 关注点 目标
L1：功能实现 “能跑通” 实现减库存+下单
L2: 高并发优化 “不超卖、不崩” 引入Redis、MQ、限流
L3: 系统工程 “可运维、可观测、可扩展” 监控、告警、压测、容灾
六、常见误区（避坑指南）
误区 正确做法
直接操作DB扣库存 先用Redis预扣，异步同步DB
用synchronized加锁 单机锁无效，必须用分布式锁或Redis原子操作
忽略幂等性 MQ重试、网络超时都可能导致重复请求
只测功能不测性能 必须JMeter压测，验证极限QPS
把秒杀和主站部署在一起 独立部署！避免拖垮整个电商系统
七、总结：一句话认识高并发秒杀系统
高并发秒杀系统=流量过滤X缓存前置x异步解耦x原子操作x最终一致
结束语--它不是炫技，而是在极端压力下，用工程手段平衡性能、正确性与成本
