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