秒杀开始的瞬间，最有价值的判断不是“要不要加队列”，而是“系统里哪一段最不能被瞬时流量直接砸中”。同步下单的路径通常是：请求进来，校验库存，扣减，写订单，返回结果。这条链路里，数据库的写入能力是硬上限，几百毫秒内涌入的请求量一旦超过它，连接池被占满、响应变慢，后续请求继续堆积，最后连正常交易都被拖住。
队列改变的是请求的节奏
消息队列削峰并非提升处理能力，它的作用是把不可控的到达曲线改写成可控的消费曲线。用户的抢购请求先落进队列就返回“排队中”，后台消费者按数据库能承受的速率匀速取任务、扣库存、建订单。峰值被摊平，数据库面对的是稳定压力，而不是一波浪头。
这个机制成立的前提，是前面还有一道过滤。网关限流、库存预扣这些动作要在入队之前完成，否则队列只是把无效请求和重复请求也照单收下，积压反而更难处理。原文把消息队列削峰列为秒杀架构的核心成本项之一，原因也在这里：它需要和缓存扣减、流量漏斗配套设计，单独挂一个队列解决不了问题。
异步之后多出来的三笔账
第一笔是幂等。消息可能重复投递，消费端必须以订单号或业务唯一标识做去重，否则同一笔抢购会生成多条订单。第二笔是可靠性。消息从入队到消费完成之间，任何环节失败都要有重试和补偿路径，反复失败的消息要能落到隔离区等待人工或定时处理，不能静默丢失。第三笔是结果回传。用户端拿不到同步返回值，就得靠轮询或服务端推送告知最终结果，排队中、成功、失败这几种状态都要有明确出口，否则体验会比报错更糟。
还有一件常被忽略的事：异步下单把失败从“当场报错”变成了“稍后告知”，退款、释放库存、通知用户这些善后动作必须一并设计。库存在预扣阶段就已经锁住，消费失败后不释放，等于把商品永久占死。
队列本身也有天花板。积压持续增长说明消费能力不足，此时要么扩容消费者，要么在入口处更早地拒绝请求。没有积压监控、没有降级预案的异步链路，等于把一次可预期的故障推迟到不可观测的时刻。它的价值不在于让系统扛住一切，而在于把压力变成可度量、可调度、可兜底的东西。
