Appearance
秒杀系统流量治理怎么做更稳
先说结论
- 秒杀系统第一目标不是“多快”，而是“别让热点流量直接冲垮核心链路”
- 限流、削峰、库存预扣、异步下单要配套设计，单独做一项都不够
- 能不能稳定撑住，往往取决于活动前预热和异常时降级方案，而不只是运行时参数
一、秒杀为什么不能按普通下单思路来做
普通下单的请求模型相对均匀，而秒杀场景往往具备：
- 极短时间内流量爆发
- 单个商品极端热点
- 同一用户重复点击
- 大量“本来就抢不到”的无效请求
如果这类请求直接冲进数据库和订单服务，通常第一波就会把连接池、线程池和库存表一起打抖。
二、一个更稳的治理顺序
更推荐按下面这条链路来做：
- 活动前预热商品和规则。
- 网关或活动层先限流、验资格。
- Redis 或内存层做库存预扣和一人一单判断。
- 成功请求写入消息队列异步创建订单。
- 订单服务再按正常链路落库和支付。
这样做的核心价值是把最重的数据库事务从流量最前面挪开。
三、秒杀链路里最关键的三道闸
1. 资格校验闸
在真正抢购前先挡掉明显无效流量：
- 未登录
- 不在活动时间
- 不符合用户分层
- 重复请求过多
2. 库存闸
用 Redis 原子扣减或 Lua 控制库存预扣，尽量不要让所有请求都直接更新数据库库存行。
3. 下单闸
就算预扣成功，也建议进入消息队列异步创建订单，避免活动峰值直接把订单服务拖满。
四、最容易踩的坑
1. 一上来就连数据库扣库存
并发一高，库存表很快成为热点行，锁冲突和连接占满会非常明显。
2. 只做限流，不做降级
活动流量超出预期时，如果没有“秒杀页降级、非核心能力关闭、排队提示”这类方案，再好的限流规则也容易把用户体验打碎。
3. 预扣成功后没有兜底回补
如果消息丢失、订单创建失败、支付超时，没有库存回补机制，库存数据很快会错。
4. 只压测接口，不压测活动流程
秒杀真正的压力不只在接口 QPS，还在：
- Redis 热点
- 消息堆积
- 订单回写
- 支付回调
- 失败补偿
五、活动前至少要准备什么
- 商品、库存、活动规则预热
- 限流阈值和开关预案
- MQ 堆积告警
- 库存回补脚本或任务
- 页面降级和熔断方案
- 活动期间的实时看板
总结
秒杀系统流量治理的本质，不是某个组件多快，而是能不能把无效流量挡在前面，把真实成交流量削峰后送进后面的订单链路。资格校验、库存预扣、异步下单和异常降级一起做，系统才真正稳。