项目场景:
修改秒杀业务,要求同一个优惠券,一个用户只能下一单
问题描述
优惠卷是为了引流,但是目前的情况是,一个人可以无限制的抢这个优惠卷,所以我们应当增加一层逻辑,让一个用户只能下一个单,而不是让一个用户下多个单
具体操作逻辑如下:比如时间是否充足,如果时间充足,则进一步判断库存是否足够,然后再根据优惠卷id和用户id查询是否已经下过这个订单,如果下过这个订单,则不再下单,否则进行下单
初步代码:增加一人一单逻辑
@Override
public Result seckillVoucher(Long voucherId) {
// 1.查询优惠券
SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
// 2.判断秒杀是否开始
if (voucher.getBeginTime().isAfter(LocalDateTime.now())) {
// 尚未开始
return Result.fail("秒杀尚未开始!");
}
// 3.判断秒杀是否已经结束
if (voucher.getEndTime().isBefore(LocalDateTime.now())) {
// 尚未开始
return Result.fail("秒杀已经结束!");
}
// 4.判断库存是否充足
if (voucher.getStock() < 1) {
// 库存不足
return Result.fail("库存不足!");
}
// 5.一人一单逻辑
// 5.1.用户id
Long userId = UserHolder.getUser().getId();
int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
// 5.2.判断是否存在
if (count > 0) {
// 用户已经购买过了
return Result.fail("用户已经购买过一次!");
}
//6,扣减库存
boolean success = seckillVoucherService.update()
.setSql("stock= stock -1")
.eq("voucher_id", voucherId).update();
if (!success) {
//扣减库存
return Result.fail("库存不足!");
}
//7.创建订单
VoucherOrder voucherOrder = new VoucherOrder();
// 7.1.订单id
long orderId = redisIdWorker.nextId("order");
voucherOrder.setId(orderId);
voucherOrder.setUserId(userId);
// 7.3.代金券id
voucherOrder.setVoucherId(voucherId);
save(voucherOrder);
return Result.ok(orderId);
}
出现问题:上述代码通过
int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
去数据库根据用户id和优惠券id查询订单里面是否已经有了用户抢购的唯一记录,若count ==0
代表是用户初次下单,则去执行下面的优惠券扣减动作,反之则给用户返回只能下单一次的错误信息。但是在高并发的情况下,就会导致多个线程进入sql语句判断
count ==0
的情况,导致一个用户可以对优惠券的多次扣减。
存在问题:现在的问题还是和之前一样,并发过来,查询数据库,都不存在订单(count ==0
的情况),所以我们还是需要加锁,但是乐观锁比较适合更新数据,而现在是插入数据,所以我们需要使用悲观锁操作
注意:在这里提到了非常多的问题,我们需要慢慢的来思考,首先我们的初始方案是封装了一个createVoucherOrder方法,同时为了确保他线程安全,在方法上添加了一把synchronized 锁
@Transactional
public synchronized Result createVoucherOrder(Long voucherId) {
Long userId = UserHolder.getUser().getId();
// 5.1.查询订单
int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
// 5.2.判断是否存在
if (count > 0) {
// 用户已经购买过了
return Result.fail("用户已经购买过一次!");
}
// 6.扣减库存
boolean success = seckillVoucherService.update()
.setSql("stock = stock - 1") // set stock = stock - 1
.eq("voucher_id", voucherId).gt("stock", 0) // where id = ? and stock > 0
.update();
if (!success) {
// 扣减失败
return Result.fail("库存不足!");
}
// 7.创建订单
VoucherOrder voucherOrder = new VoucherOrder();
// 7.1.订单id
long orderId = redisIdWorker.nextId("order");
voucherOrder.setId(orderId);
// 7.2.用户id
voucherOrder.setUserId(userId);
// 7.3.代金券id
voucherOrder.setVoucherId(voucherId);
save(voucherOrder);
// 7.返回订单id
return Result.ok(orderId);
}
出现问题: 因为需要实现的一人一单,只是规定了一个用户只能下一单,但是不妨碍其他的用户去下单,这样的话直接在方法体上加
synchronized
会导致当前用户在下单,别的用户也要在外面等待,效率就会很差。
解决方案:
这样添加锁,锁的粒度太粗了,在使用锁过程中,控制锁粒度 是一个非常重要的事情,因为如果锁的粒度太大,会导致每个线程进来都会锁住,所以我们需要去控制锁的粒度,以下这段代码需要修改为:
intern() 这个方法是从常量池中拿到数据,如果我们直接使用userId.toString() 他拿到的对象实际上是不同的对象,new出来的对象,我们使用锁必须保证锁必须是同一把,所以我们需要使用intern()方法
``
@Transactional
public Result createVoucherOrder(Long voucherId) {
Long userId = UserHolder.getUser().getId();
synchronized(userId.toString().intern()){
// 5.1.查询订单
int count = query().eq("user_id", userId).eq("voucher_id", voucherId).count();
// 5.2.判断是否存在
if (count > 0) {
// 用户已经购买过了
return Result.fail("用户已经购买过一次!");
}
、、、、、、、、、、、、、
出现问题: 以上代码还是存在问题,问题的原因在于当前方法被spring的事务控制,如果你在方法内部加锁,可能会导致当前方法事务还没有提交,但是锁已经释放也会导致问题,所以我们选择将当前方法整体包裹起来,确保事务不会出现问题:如下:
在seckillVoucher
方法中,添加以下逻辑,这样就能保证事务的特性,同时也控制了锁的粒度
@Override
// @Transactional 数据库操作放在 封装方法体里面 方法体加了事务锁 这里不需要加事务了
public Result seckillVoucher(Long voucherId) {
//1.查询优惠券信息
SeckillVoucher voucher = seckillVoucherService.getById(voucherId);
//2.根据优惠券的开始时间判断秒杀是否开始
boolean isBegin = voucher.getBeginTime().isAfter(LocalDateTime.now());
if (isBegin) {
// 尚未开始
return Result.fail("秒杀尚未开始");
}
// 3.判断秒杀是否已经结束
boolean isBefore = voucher.getEndTime().isBefore(LocalDateTime.now());
if (isBefore) {
// 秒杀已经结束
return Result.fail("秒杀已经结束");
}
// 4.判断库存是否充足
if (voucher.getStock() < 1) {
// 库存不足
return Result.fail("库存不足!");
}
Long userId = UserHolder.getUser().getId();
synchronized (userId.toString().intern()) {
return this.createVoucherOrder(voucherId);
}//调用封装 一人一单(悲观锁) 并且 不超卖(乐观锁)
}
提示:但是以上做法依然有问题,因为你调用的方法,其实是
this.
的方式调用的,事务想要生效,还得利用代理来生效,所以这个地方,我们需要获得原始的事务对象, 来操作事务
//若将事务注解加此方法上:
// 事务是采用的mapper
代理方式实现;
// 调用此方法时 是采用this.
方法()是非代理对象 是没有事务功能的
//因此需要在调用处拿到这个方法的代理对象 才能使事务生效
Long userId = UserHolder.getUser().getId();
synchronized (userId.toString().intern()) {
//获取代理对象(事务)
IVoucherOrderService proxy = (IVoucherOrderService) AopContext.currentProxy();
return proxy.createVoucherOrder(voucherId);
}//调用封装 一人一单(悲观锁) 并且 不超卖(乐观锁)
这里需要引入依赖包
<dependency>
<groupId>org.aspectj</groupId>
<artifactId>aspectjweaver</artifactId>
</dependency>
</dependencies>
并且在启动类上加上注解
@EnableAspectJAutoProxy(exposeProxy = true)
提示:
exposeProxy = true
是该注解的一个可选属性,用于决定是否将代理对象暴露给AopContext
,以便在切面内部访问当前代理对象。默认情况下,exposeProxy
的值为false
,即不暴露当前代理。如果将exposeProxy
设置为true
,可以通过AopContext.currentProxy()
方法在切面内部获取当前代理对象。
集群环境下的并发问题:
通过加锁可以解决在单机情况下的一人一单安全问题,但是在集群模式下就不行了。
1、我们将服务启动两份,端口分别为8081和8082:
2、然后修改nginx的conf目录下的nginx.conf文件,配置反向代理和负载均衡:
有关锁失效原因分析
由于现在我们部署了多个
tomcat
,每个tomcat
都有一个属于自己的jvm
,那么假设在服务器A的tomcat
内部,有两个线程,这两个线程由于使用的是同一份代码,那么他们的锁对象是同一个,是可以实现互斥的,但是如果现在是服务器B的tomcat
内部,又有两个线程,但是他们的锁对象写的虽然和服务器A一样,但是锁对象却不是同一个,所以线程3和线程4可以实现互斥,但是却无法和线程1和线程2实现互斥,这就是 集群环境下,syn锁
失效的原因,在这种情况下,我们就需要使用分布式锁
来解决这个问题。
分布式锁参考链接: