秒杀下单，用户点一下按钮，后端要过六道关卡

秒杀下单这个动作用户端看到的是点一下按钮后端要做的事情比大多数人想的要多。一个请求进来要过六道关卡机审校验、用户级限流、活动校验、小黑屋检查、库存预检全部通过后才发一条MQ消息进入排队。这六步都在同步阶段完成用户等待的时间里后端已经把无效请求挡在了门外。真正的库存扣减和订单创建交给消费端异步处理。这里面有两个容易被忽略的设计细节一个是校验顺序。机审和限流放在最前面因为它们只需要一次Redis操作代价最低却能挡掉绝大部分无效请求。如果把活动校验或库存查询放前面每个请求都要查缓存、读数据高并发下这些开销是不必要的。代价低的校验放前面这个排列顺序直接影响系统在峰值时的吞吐量。另一个是库存预检和库存扣减的关系。预检读的是Redis里的库存快照不是精确值。10个请求同时读到库存为1都会通过预检进入MQ但最终只有一个能扣减成功。预检的目的不是精确判断而是快速拦截已经售罄的情况减少无效的MQ消息量。精确扣减在消费端用Lua脚本原子操作完成这两层配合才是完整的库存控制方案。还有一个实际运维的考量每个校验环节是独立的Service大促期间某个环节出问题比如机审误杀率突然升高通过Nacos把对应的开关关掉就行不影响其他环节。这种可插拔的编排方式在线上真出事的时候能少很多麻烦。这些设计不是凭空想出来的是从真实的生产系统里提炼出来的。我正在写的「秒杀系统实战」专栏目前已经更新到第11篇从需求PRD、技术方案设计、基础框架搭建到网关限流、分库分表、多级缓存、机审校验、用户级限流、小黑屋再到这篇的下单入口每一篇都带完整的代码实现和设计决策的推导过程。后续还有RocketMQ实践、Lua脚本库存扣减、订单生成、支付回调、风控体系这些内容30篇写完就是一套从0到1的秒杀系统落地方案。感兴趣的可以到专栏看看每篇都能直接拿去用。专栏发布在知乎里我的知乎账号:SamDeepThinking