- 数据库实现 乐观锁
sql
update tsec_kill
set num = num - #{buys}
where
sku = #{sku} and num - #{buys} >= 0
问题：数据库读写瓶颈
- 缓存实现
Redis原生原子操作
系统设计
- 一键秒杀引导
一键秒杀引导设置后无需再结算页面输入/修改 地址 优惠 发票等元素，减少结算新再次计算和调用操作
- 验证码输入
- 下单页面防止恶意请求
下单地址动态化，动态地址再商品秒杀开始时返回给页面 防止恶意请求
- 秒杀库存预冻结
秒杀活动创建的时候商品库存预冻结，库存中心添加一种冻结类型
秒杀成功后直接使用改库存生成订单，订单中心增加一种秒杀订单类型
- 库存释放
不付款或者取消订单
一：进行库存释放，用户可以再次抢购（秒杀系统调用库存中心释放库存）
- 数据交互内存操作
可以使用redis 预加载数据
比如 库存计数器 用户违规操作（同ip时间内访问频率过高，同用户访问频率过高，黑名单，） Redis表的键值设置会尽量遵从最短执行/扫描路径设计
- 内存操作的数据对象
库存计数器 服务器节点接受的请求计数器 用户参与秒杀记录（针对 时间 商品 活动） 预生成订单vo 秒杀商品信息 访问控制数据
- 预加载到内存的时机
库存计数器 ---秒杀活动创建 递减
服务器节点接受的请求计数器-- 递减
用户参与秒杀记录（针对商品） -- 秒杀成功
用户参与秒杀记录（针对活动）-- 秒杀成功
用户参与秒杀记录（针对时间段）-- 秒杀成功
预生成订单vo -- 秒杀活动创建后
用户验证码 -- 用户点击 一键秒杀
秒杀商品活动信息 -- 秒杀活动创建
访问控制数据 -- 请求进入
- 系统隔离
第一期需要以来的模块
活动运行时依赖; 支付中心，库存中心，订单中心（库存释放）
活动开始前依赖： 商品中心， 会员中心，商家后台
- 秒杀库存计数器
通过Redis的原子自增锁实现 decr incr
- 请求的四次拦截 js处理高频点击处理限制
第一次：请求错流 验证码输入，将流量错开 减少并发
第二次：恶意流量拦截 过滤掉恶意请求 （部分）
第三次：服务节点拦截 每个服务节点允许下单的流量等于商品的库存数，其他请求提示秒杀已经抢完 到达秒杀持久化层的流量 = 服务节点数 * 库存数
第四次：到达秒杀持久层的请求数等于库存+N（N为溢出值），其他提示秒杀抢完
- 秒杀页面独立
该页面只调用秒杀系统，减少营销借接口的压力
- 秒杀成功订单持久化操作
如果持久化的量非常高 可以考虑使用消息队列来实现