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

今天你写代码了吗？？

已于 2023-07-06 14:45:56 修改

阅读量917

点赞数 2

分类专栏：黑马点评 Redis 文章标签：性能优化数据库

于 2023-07-06 13:50:21 首次发布

本文链接：https://blog.csdn.net/weixin_45618869/article/details/131574131

版权

Redis 同时被 2 个专栏收录

13 篇文章

订阅专栏

黑马点评

10 篇文章

订阅专栏

文章讨论了在秒杀业务中如何防止一个用户获取多张优惠券的问题。通过增加逻辑判断，如检查时间、库存以及用户是否已下单，初步实现了限制。然而，在高并发情况下，使用悲观锁和乐观锁控制一人一单仍存在并发问题。在单机环境下，通过用户ID作为锁对象并使用`synchronized`关键字进行控制，但在集群环境中，需要转向分布式锁来解决跨JVM的并发问题。文章还提到了事务管理和AOP在处理事务中的作用，以及在集群环境下分布式锁的必要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

项目场景：

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

问题描述

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

具体操作逻辑如下：比如时间是否充足，如果时间充足，则进一步判断库存是否足够，然后再根据优惠卷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：

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-NGvo1mns-1688625551664)(.\Redis实战篇.assets\1653373887844.png)]$

2、然后修改nginx的conf目录下的nginx.conf文件，配置反向代理和负载均衡：

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-s7gBlaTK-1688625551665)(.\Redis实战篇.assets\1653373908620.png)]$
有关锁失效原因分析

由于现在我们部署了多个tomcat，每个tomcat都有一个属于自己的jvm，那么假设在服务器A的tomcat内部，有两个线程，这两个线程由于使用的是同一份代码，那么他们的锁对象是同一个，是可以实现互斥的，但是如果现在是服务器B的tomcat内部，又有两个线程，但是他们的锁对象写的虽然和服务器A一样，但是锁对象却不是同一个，所以线程3和线程4可以实现互斥，但是却无法和线程1和线程2实现互斥，这就是集群环境下，syn锁失效的原因，在这种情况下，我们就需要使用分布式锁来解决这个问题。

在这里插入图片描述
分布式锁参考链接：