商品秒杀项目

商品秒杀项目（思路版）

需要的数据库表

• 商品表
• 订单表
• 秒杀商品表
• 秒杀订单表 包括秒杀商品id和用户id

简单流程

• 点击秒杀
• 是否登录
• 查询库存（库存=0,商品被抢空）
• 查询重复购买(每人只允许在秒杀订单表中只有一条数据)
• 可以秒杀
  • 秒杀商品库存-1
  • 生成订单
  • 生成秒杀订单
• 至此秒杀成功

库存超卖

JMeter

一款测压工具

测试发现，1000个线程即1000个用户同时秒杀，会产生大量的订单

流程分析

• 在高并发下，很多请求同时查询到商品库存信息
• 当两个用户并发SELECT库存后，两个用户获取到的库存是相等的，再UPDATE设置库存-1，相当于只减少了一件
• 因为查询库存和库存-1的操作不是一个原子操作
• 所以解决方案主要就是对查库存修改库存两步操作的原子化

超卖解决方案

悲观锁（syncronized）

在秒杀service方法上添加syncronized来上锁，来保证秒杀服务是串行执行的（有问题，看注意）。需要把syncronized加在controller层，这样就比事务的范围大了

注意:如果事务注解@Transactional添加状态下，对方法进行加锁，仍然会出现错误，因为当一个加锁方法执行完成后，由于事务的存在，当前线程的服务并没有被提交，这时新的线程到来，拿到的仍然是旧的库存，从而产生超卖

问题：悲观锁同一时间只允许一个线程运行，对用户体验很差

乐观锁

利用数据库定义的version字段，表示当前修改的版本，很多JUC的API都使用了类似的思想，添加stamp表示版本信息（此内容查看我的JUC专题）

获取库存的同时获取当前版本号，修改库存时修改version=version+1并且WHERE 中添加 version = #{versionId} ，如果在两步操作之间其他用户修改了库存也会修改version，就会让本线程修改失败（因为根据WHERE version = #{versionId} 已经查不到该条数据了，就会返回0），这样多线程并发情况下，只有一个线程能完成对库存的修改