秒杀系统基础架构

• 首先前端打开页面时使用ajax查询redis库存接口，有库存则显示下单按钮，否则禁用下单

• 点击下单，调用后端接口，先查redis库存，若有库存则进入一级排队队列，返给前端一个序列号，前端显示进入排队，并开始轮询结果队列（使用序列号轮询）

• 每一级队列中的消息体中的排队时间都是一级队列入队时的时间，按照该时间判断付款超时

• 订阅了一级队列的独立进程对一级队列进行去重过滤（重复的消息直接发送结果队列（包含序列号），错误码为重复下单）

• 对过滤出来的有效消息入二级队列，并将用户id写入redis，用于去重判断。

• 二级队列每处理一个消息，则减一个redis库存，然后发给三级队列；若redis库存不足，则暂停消耗二级队列，等待redis库存加回

• 处理三级队列，写库：创建实际订单，减实际库存，等待付款，写结果队列（包含序列号，下单成功，等待付款）

• 定时任务（每2s扫描一次未付款订单）超时未付款的作废处理：作废订单，加实际库存，加redis库存，在redis去重队列中清除对应用户的id

• 成功付款，不能清除redis去重队列中对应用户的id

思考一下：

1. 为什么要用三级队列的结构？

2. 前两次判断库存走的是Redis，第三次走的是DB，为什么要这样设计，有什么好处？

3. 是先判断库存再减，还是先减库存再判断？为什么？

4. Redis是否存在并发问题？
   

5. 结果队列如何设计？前端的轮询策略是什么？

6. Redis中的用户ID缓存之所以不清除成功付款的用户ID，是因为我们假设每个用户只能购买一次。那么什么时候可以将用户ID从这个缓存中移除？你会怎么设计这个流程？

7. 上面的架构如何避免超卖？

更多架构方便精彩文章，请关注如下公众号：