昨天审代码，看到新人写的秒杀逻辑，差点没把我气乐了。他在Redis里用Lua脚本扣完库存后，非要先去数据库再扣一次，然后再发RabbitMQ。我问他为啥这么干，他说怕“数据不一致”。 这就是典型的“学生思维”遇上了“真实的高并发战场”。 如果秒杀环节还得实时去操作数据库扣库存，那你引以为傲的Redis和MQ全是摆设。几万人的流量瞬间涌进来，数据库的行锁（Row Lock）瞬间就能把系统卡死。这就好比你在高速公路上非要设个人工收费站，后面绝对堵成停车场，服务器直接502。 真正的抗压方案，核心逻辑必须是“挡在门外，异步处理”。 给还在纠结这个流程的朋友拆解一下真正能落地的方案： 1. Redis是唯一的“守门员”： 所有的库存扣减，只认Redis。Lua脚本保证原子性，Redis里扣减成功了，就相当于发了“入场券”。没拿到的，直接在网关层就挡回去，根本不让它们碰数据库。 2. MQ是“缓冲区”： 拿到入场券的请求，直接丢进RabbitMQ。这时候，你的API就可以直接给前端返回“排队中”，让用户在那转圈圈等待结果。这一步千万别去碰DB。 3. 数据库操作是“收尾工作”： 真正扣减数据库库存的动作，是在MQ的消费者端进行的。 消费者拿到消息后，开启一个本地数据库事务：既写入订单表，又扣减商品库存表。 注意，这两个动作是在同一个本地事务里完成的，天然保证了原子性。如果执行失败，MQ重试即可。根本不需要在前面搞什么复杂的分布式事务。 有人肯定会担心：“那万一Redis扣了，MQ没发出去，或者是Redis挂了数据丢了咋办？” 这时候才需要用到“本地消息表”或者MQ的发送确认机制来兜底。但在秒杀这个极端场景下，“严防超卖”和“系统存活”比“数据的绝对实时一致性”重要一万倍。 哪怕因为Redis故障少卖了两个库存，也比数据库被打挂、全平台宕机要强得多。 做架构就是做取舍，哪有什么完美的强一致性？在高并发面前，大多都是在用“最终一致性”换性能。 你们公司的秒杀系统，是还在傻傻地锁数据库，还是已经用上这套异步打法了？评论区聊聊你们踩过的坑。