Redis 队列方案

数据库无法承受秒杀瞬时峰值时，可以把库存扣减前置到 Redis。Redis 承担高频库存预扣，数据库只处理已经抢到资格的请求。

用户请求 -> Redis 扣库存 -> 入队 -> 异步创建订单 -> 支付确认

本章主线

本章包括三个关键点：

1. Redis 扣减：用原子操作快速判断是否还有库存。
2. 队列串行化：把成功预扣的请求写入队列，异步创建订单。
3. 异步下单：用户先拿到排队结果，再查询最终订单状态。

为什么要队列

Redis 扣库存只能说明用户抢到了“下单资格”，不能代表订单已经创建。队列的作用是把瞬时成功请求削成后台可处理的稳定流量。

这样可以保护数据库：

• 库存不足的请求在 Redis 层被拦截。
• 成功请求进入队列，按消费者能力处理。
• 数据库只面对有限成功流量。

用户体验

异步方案会改变体验。用户点击抢购后，不能立刻看到订单，而是看到：

抢购请求已提交，请稍后查看结果

前端可以轮询订单状态，或通过消息通知结果。这里的关键是让用户知道系统正在处理，而不是无限 loading。

风险边界

Redis 队列方案引入新问题：

• Redis 预扣成功但创建订单失败，库存如何释放？
• 队列积压时用户等待多久？
• 消费重复时是否会创建重复订单？
• Redis 库存和数据库库存如何对账？

因此，Redis 方案必须配合幂等订单、库存补偿和对账任务。下一章会进一步讨论限流削峰，把无效流量挡在更前面。