可落地秒杀核心流程图

如果有规定时间内未支付、支付不成功或其他情况出现时，清除订单，回滚商品量。一般在20分钟一个周期，直到支付成功数量和商品秒杀库存相等结束。

改变

判断版本号是否被改变

用户3

失败提示（如短信方式）

第一道过滤无效流量redis中存一个key来保存当前商品余量（初始值为商品总量）过滤流量减轻之后主业务压力

提示用户下单完成，等待下单结果（）。

未超，扣减

符合

支付是否成功

CAS分布式乐观锁

redis中获取版本号

注意：这里如果附加条件多，则需要关键KEY的内容转JSON以存储需要判断规则的数据结构。如果实际业务场景规则太多，单次抢购产品量太多，建议使用memcache

最终提示（如短信方式）

图2：CAS机制图

判断购买量是否超余量

秒杀核心流程图

图1：整体流程图

定时器回写数据库商品总量

控制库存超卖情况。

成功

实现代码：https://juejin.im/post/5a372fba51882512b67ac64f

用户1

1、不成功2、规定时间内未支付

开始

是否还有库存（判断数据依据从redis拿）

注意：这里2次从redis中拿了余量做判断是否余量为0。原因是：1、方便业务隔离因为第一次拿余量判断的量远大于第二次，所以可以把第一次的redis余量独立出来，然后通过一个频率较高的线程去不停判断第二个redis的余量是否为0，如果为0同步到第一个redis余量中，使得后面的访问在第一个redis的余量判断后就不会继续走后面的流程，节约硬件资源。2、第二个redis的余量在cas机制中的会随着实际情况改变的，并且由于他在cas机制中，所以比起第一个redis的获取余量来说要重不少，所以如果能在第一个redis的余量中就隔离流量能尽可能小的影响到这里的业务和其他业务。

第二道过滤流量提示用户不在购买规则内具体内容减轻主业务中控制超卖和下单压力

处理订单流程

附一：购买规则1、购买量超过本次商品单用户购买总量限额；2、购买量超过单用户单次购买上限；3、购买次数超过单用户购买次数上限；4、购买量超过用户可购买剩余量；5、购买量超过剩余库存；6、黑名单（本次不实现）7、防刷验证机制（本次不实现）8、其他规则

库存超卖通过CAS控制，如果购买规则不加入CAS机制，可能会出现违反规则的订单。但是在规则中加入CAS机制会使得watch的key的值比较重，特别是秒杀的产品多，和产品以及用户相关的规则多的时候，越多越重。

尝试余量回写到redis中

用户2

主业务

不符合

商品0

注意：redis事物仅能保证多条事物中的语句被提交后执行时，不会被其他提交插入打断，不能保证其中有一条出错了回滚

记录到redis中订单队列

1、库存不够，未成功2、超时机制或超重试次数

是否下单成功

商品为0

失败

提示用户抢购失败，商品已经被抢购完

1、扣减后的余量回写redis2、修改版本号

1、订单请求

成功，提示用户

超过，结果

是否符合购买规则（判断数据依据从redis拿）详见附一

redis中获取余量

没改变