用户的请求打到OpenResty，<br>通过OpenResty去请求秒杀的<b><font color="#ff0000">频道</font></b>和<b><font color="#ff0000">商品详情页</font></b><br>
去redis中请求<b><font color="#ff0000">秒杀列表页</font></b>的数据
如果用户点击了某个具体的商品，那么商品详情页的数据页也是从redis中读取
用户进行了下单<br>
需要检验是否有库存，通过OpenResty检验库存，<br>库存数据在redis中（通过OpenResty将大量无效的请求过滤掉，<br>即这部分不合法的请求压根就不会进入到我们的微服务系统中去）<br>
如果库存充足，则验证用户有没有登录
未登录，进行OAuth2.0授权登录
进入秒杀微服务<br>
<b><font color="#ff0000">不采用传统的抢单模式</font></b>，传统抢单模式，需要进行一系列的校验，<br>校验通过后<b><font color="#ff0000">才有资格进行抢单</font></b>，但是这一些校验<b><font color="#ff0000">非常耗时</font></b>，<br>因此在大量请求下很容易出问题（所有请求都会阻塞在这里，服务会被搞挂掉）。<br>一系列的校验包括：<br>
账号是否异常
24小时内是否购买过该商品
是否存在未支付的秒杀商品
<span style="font-family: "Open Sans", "Clear Sans", "Helvetica Neue", Helvetica, Arial, sans-serif; font-size: 16px; orphans: 4; white-space: pre-wrap;"><font color="#ffffff">该秒杀商品是否还有库存</font></span><br>
该秒杀商品抢购人数是否达到上线<br>
使用队列模式，将抢单信息（包含订单信息、商品信息、用户信息）存储到redis的队列中<br>（需要有用户排队信息队列用来标识用户是否重复排队，需要有用户排队状态队列，用于检测用户的排队状态 ），<br>避免服务器一口气处理所有请求，达到削峰减流的一个效果，避免服务器被搞挂<br>
进入redis队列后，提示用户进入了排队当中
同时后台利用多线程进行一个下单操作（多线程抢单）
多线程下单也要检查传统抢单模式中信息，只有校验通过后才有资格抢单
同时利用redis中的原子操作去实现库存的递减
下单成功后会同步更新用户排队的状态
用户就抢单成功进入<b><font color="#ff0000">支付环节</font></b>了，<b><font color="#ff0000">用户支付成功后，将redis中的订单信息删除掉</font></b>
同时会插入一条延时消息到延迟队列中（包含订单信息、商品信息、用户信息）
当延迟时间到了后，取出来查看下redis中是否有这个订单，<br>如果有（如果支付完成了，redis中的订单数据就被移除了），<br>表示还未完成支付，那么进行取消订单的操作（<b><font color="#ff0000">关闭支付、清理订单、回滚库存</font></b>）<br>
