黑马点评之一人一单锁和事务的处理问题

项目场景：

修改秒杀业务，要求同一个优惠券，一个用户只能下一单

---

问题描述

优惠卷是为了引流，但是目前的情况是，一个人可以无限制的抢这个优惠卷，所以我们应当增加一层逻辑，让一个用户只能下一个单，而不是让一个用户下多个单

具体操作逻辑如下：比如时间是否充足，如果时间充足，则进一步判断库存是否足够，然后再根据优惠卷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.用户idLong 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.订单idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);voucherOrder.setUserId(userId);// 7.3.代金券idvoucherOrder.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.订单idlong orderId = redisIdWorker.nextId("order");voucherOrder.setId(orderId);// 7.2.用户idvoucherOrder.setUserId(userId);// 7.3.代金券idvoucherOrder.setVoucherId(voucherId);save(voucherOrder);// 7.返回订单idreturn 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锁失效的原因，在这种情况下，我们就需要使用分布式锁来解决这个问题。

分布式锁参考链接：