完整系统

完整秒杀系统可以分成五层：

流量入口 -> 风控限流 -> Redis 预扣 -> 队列下单 -> 支付确认与库存对账

每一层都在削减风险：入口层挡掉异常流量，限流层控制规模，Redis 层快速判断库存，队列层削峰，数据库层保存最终事实。

最终流程

一次秒杀请求可以这样处理：

1. 用户进入活动页，完成预约或资格校验。
2. 网关和风控服务过滤异常请求。
3. 限流系统控制进入核心链路的请求量。
4. Redis Lua 脚本原子预扣库存。
5. 预扣成功的请求进入订单队列。
6. 订单消费者幂等创建待支付订单。
7. 用户支付成功后确认库存。
8. 超时未支付订单释放库存。
9. 对账任务修复 Redis、订单、数据库库存差异。

关键决策

1. 数据库扣库存还是 Redis 预扣：数据库正确但吞吐低，Redis 高吞吐但需要补偿和对账。
2. 同步下单还是异步排队：同步体验直接，异步能削峰并保护数据库。
3. 强一致还是最终一致：库存售卖结果必须正确，展示和排队状态可以最终一致。
4. 限流放在哪里：越靠前越省资源，但越靠后越精确，需要分层配合。
5. 风控是否影响用户体验：会，但公平性和系统稳定性要求必须控制高风险流量。

上线检查清单

• 秒杀活动是否有独立库存，不直接使用普通商品库存？
• Redis 预扣是否原子，是否防止库存扣成负数？
• 队列消费者是否幂等，是否防止重复订单？
• 支付超时是否能释放库存？
• Redis 和数据库是否有库存对账任务？
• 网关、用户、活动、库存是否都有分层限流？
• 高风险账号、设备、IP 是否会被拦截或降级？
• 售罄、排队、失败结果是否对用户可解释？
• 是否压测过开抢瞬间的峰值流量？

课程总结

秒杀系统的本质是把不可承受的瞬时洪峰拆成可控阶段。它不追求所有请求都进入数据库，而是尽早过滤、限流、排队和降级，让有限库存被正确卖出。

设计秒杀系统时，始终问：

• 哪些请求应该被挡在最外层？
• 库存扣减在哪里完成，失败如何补偿？
• 用户等待结果时看到什么？
• 数据不一致如何发现和修复？

能回答这些问题，秒杀系统才具备上线能力。