小蔡学Java
  1. 首页
  2. 项目
  3. 正文

项目一总结：（十）优惠卷超卖问题的解决(1)

2024-01-30 21:05 1207 0 项目 synchronized / lock乐观锁分布式事务事务失效的场景代理模式

背景

在我的项目Online学习平台中，优惠卷是由用户领取然后使用的；但是优惠巻数量肯定是有限的，这就类似于传统电商网站中不得不面对的一个问题：超卖。下面我就来带领小伙伴们透过现象看本质，层层解析！ 前面已经展示过优惠卷的表结构设计了

优惠卷表

要想记录 谁领了那张卷 ，我们又设计了一个用户优惠卷表，来展示用户与优惠卷的关系

用户优惠卷表

分析

领卷有两种方式：手动领取、兑换码兑换

手动领取

领券的本质就是新增一条记录到user_coupon表，去记录用户和领券的优惠券之间的关系，使用状态等信息。那因此请求的需要两个参数：

  • 用户id
  • 优惠券id

不过，需要注意的是，优惠券并不是任何人来了都可以领取的，我们需要做一系列的校验：

  • 校验 优惠券是否存在 ，不存在无法领取
  • 校验优惠券的 发放时间 ，是不是正在发放中
  • 校验优惠券 剩余库存是否充足
  • 校验优惠券的 每人限领数量

只有全部校验通过，才可以领取优惠券，而领券要做两件事：

  • 新增一个记录到user_coupon表
  • 更新coupon表中已经领取的数量，别忘了在coupon表中是有一些统计字段的：

更新发行数量（已领取数量），不仅仅起到统计作用，同时也可以帮助我们判断库存是否充足。 当issue_num >= total_num时，那就证明库存已经不足了。

因此领取优惠券的业务流程如下：

代码实现

 	@Override
    @Transactional
    public void receiveCoupon(Long couponId) {
        // 1.查询优惠券
        Coupon coupon = couponMapper.selectById(couponId);
        if (coupon == null) {
            throw new BadRequestException("优惠券不存在");
        }
        // 2.校验发放时间
        LocalDateTime now = LocalDateTime.now();
        if (now.isBefore(coupon.getIssueBeginTime()) || now.isAfter(coupon.getIssueEndTime())) {
            throw new BadRequestException("优惠券发放已经结束或尚未开始");
        }
        // 3.校验库存
        if (coupon.getIssueNum() >= coupon.getTotalNum()) {
            throw new BadRequestException("优惠券库存不足");
        }
        Long userId = UserContext.getUser();
        // 4.校验并生成用户券
        checkAndCreateUserCoupon(coupon, userId, null);
    }

兑换码兑换

兑换码表结构

首先，从请求参数来说，兑换码校验并不知道优惠券id，只要告诉我们兑换码是什么，我们解析兑换码自然能得到兑换码的id。 根据兑换码id查询exchange_code表中的exchange_target_id字段，即可知道要兑换的优惠券的id了： 所以，请求参数仅仅需要code即可。

从校验过程来说，我们首先需要校验兑换码的正确性，包括两点：

  • 兑换码格式是否正确
  • 兑换码是否已经被兑换过

兑换码的格式校验可以基于我们自定义的CodeUtil中好的parseCode方法来完成，这个方法不仅仅可以校验兑换码格式，还可以解析出其中的兑换码id，方便我们根据兑换码id查询数据库。

兑换码是否兑换则要利用BitMap来实现。由于 兑换码的id刚好是递增序列 ，按照约定，兑换码id是几，我们就 找BitMap中的第几个bit位，判断是0还是1，就能得知是否兑换过了 。

那因此，当我们兑换成功后，一定要利用SETBIT命令将对应的bit位置为1，标识这个兑换码是已兑换的。

@Override
public boolean updateExchangeMark(long serialNum, boolean mark) {
    Boolean boo = redisTemplate.opsForValue().setBit(COUPON_CODE_MAP_KEY, serialNum, mark);
    return boo != null && boo;
}

流程如下

代码实现

	@Override
    @Transactional
    public void exchangeCoupon(String code) {
        // 1.校验并解析兑换码
        long serialNum = CodeUtil.parseCode(code);
        // 2.校验是否已经兑换 SETBIT KEY 4 1 ，这里直接执行setbit，通过返回值来判断是否兑换过
        boolean exchanged = codeService.updateExchangeMark(serialNum, true);
        if (exchanged) {
            throw new BizIllegalException("兑换码已经被兑换过了");
        }
        try {
            // 3.查询兑换码对应的优惠券id
            ExchangeCode exchangeCode = codeService.getById(serialNum);
            if (exchangeCode == null) {
                throw new BizIllegalException("兑换码不存在！");
            }
            // 4.是否过期
            LocalDateTime now = LocalDateTime.now();
            if (now.isAfter(exchangeCode.getExpireTime()) {
                throw new BizIllegalException("兑换码已经过期");
            }
            // 5.校验并生成用户券
            // 5.1.查询优惠券
             Coupon coupon = couponMapper.selectById(exchangeCode.getCouponId());
            // 5.2.查询用户
            Long userId = UserContext.getUser();
            // 5.3.校验并生成用户券，更新兑换码状态
            checkAndCreateUserCoupon(coupon, userId, serialNum);
        } catch (Exception e) {
            // 重置兑换的标记 0
            codeService.updateExchangeMark(serialNum, false);
            throw e;
        }
    }

接下来看看核心方法 UserCouponServiceImpl#checkAndCreateUserCoupon（）

 private void checkAndCreateUserCoupon(Coupon coupon, Long userId, Integer serialNum){
        // 1.校验每人限领数量
        // 1.1.统计当前用户对当前优惠券的已经领取的数量
        Integer count = lambdaQuery()
                .eq(UserCoupon::getUserId, userId)
                .eq(UserCoupon::getCouponId, coupon.getId())
                .count();
        // 1.2.校验限领数量
        if(count != null && count >= coupon.getUserLimit()){
            throw new BadRequestException("超出领取数量");
        }
        // 2.更新优惠券的已经发放的数量 + 1
        couponMapper.incrIssueNum(coupon.getId());
        // 3.新增一个用户券
        saveUserCoupon(coupon, userId);
        // 4.更新兑换码状态
        if (serialNum != null) {
            codeService.lambdaUpdate()
                    .set(ExchangeCode::getUserId, userId)
                    .set(ExchangeCode::getStatus, ExchangeCodeStatus.USED)
                    .eq(ExchangeCode::getId, serialNum)
                    .update();
        }
    }

面对的问题

基于页面UI的功能性测试，是不能测出来问题的，那都没有并发呀！

要知道领券的过程中有大量的校验，这些校验逻辑在高并发的场景下很容易出现问题。因此，我们必须对领券功能做并发测试，看看是否会出现并发安全问题。

超卖问题

经过测试，确实出现了超卖（或超发）的现象，优惠只有100个库存，结果发放了109张券！！ 那么，为什么出现了超卖的现象呢？

分析原因

现在我们对于优惠券库存的处理逻辑是这样的：

  • 查询优惠券
  • 判断库存是否充足（领取数量<总数量）
  • 如果充足，更新优惠券领取数量

这里采用的是：先查询，再判断，再更新

三步操作并不具备原子性。单线程的情况下确实没有问题。但如果是多线程并发运行，如果N个线程同时去查询（N大于剩余库存），此时大概率查询到的库存是充足的，然后判断库存自然没问题。最后一起更新库存，自然就会超卖。

总结一下，原因是：

  • 多线程并行运行
  • 多行代码操作 共享资源，但不具备原子性

解决方案

我们这里最初是使用了优化后的乐观锁解决的问题:不熟悉乐观锁请看：乐观锁的理解与使用

我们无需判断issue_num是否与原来一致，只要判断issue_num是否小于total_num即可。这样，只要issue_num小于total_num，不管有多少线程来执行，都会成功。

UPDATE coupon SET issue_num = issue_num + 1 WHERE id = 1 AND issue_num < total_num

需要注意的是，where条件不成立不会报错，而是更新失败，返回0 . 因此，我们还应该对这个方法的返回值做判断，如果返回值是0，则应该抛出异常，触发回滚。

超卖这样的线程安全问题，解决方案有哪些？

  • 悲观锁：添加同步锁，让线程串行执行

    • 优点：简单粗暴
    • 缺点：性能一般

  • 乐观锁：不加锁，在更新时判断是否有其它线程在修改

    • 优点：性能好
    • 缺点：存在成功率低的问题

依然存在问题

锁失效问题

其实，除了优惠券库存判断，领券时还有对于 用户限领数量的判断：

可以看到，这部分逻辑也是按照三步走：

  • 查询数据库
  • 判断是否超出限领数量
  • 新增用户券

这段代码没有加锁，不具备原子性，如果多线程并发访问，肯定会出现安全问题。 怎么办？

是不是跟上节课一样，使用乐观锁解决？

显然不行，因为乐观锁常用在更新，而且这里用户和优惠券的关系并不具备唯一性，因此新增时无法基于乐观锁做判断。

所以，这里只能采用悲观锁方案，也就是大家熟悉的Synchronized或者Lock.

用户限领数量判断是针对单个用户的,所以我同步代码块的锁指定为用户id

注意：上述代码还是有问题的：我们刚才的锁是userId.toString();

toString()源码如下

intern()方法：只要两个字符串equals的结果为true，那么intern就能保证得到的结果用 ==判断也是true，其原理就是 获取字符串字面值对应到常量池中的字符串常量 。因此只要两个字符串一样，intern()返回的一定是同一个对象。

所以我们改造为

事务边界问题

你以为没问题了，No 其实还有 哈哈哈

经过同步锁的改造，理论上用户限领数量判断的逻辑应该已经是解决了。 不过，经过测试后，发现问题依然存在，用户还是会超领。这又是怎么回事呢？

分析原因

其实这次的问题并不是由于锁导致的，而是由于事务的隔离导致。 要知道，整个领券发放是加了事务的：

而在发放内部，我们加锁，处理限领数量的判断。

整体业务流程是这样的：

  1. 开启事务
  2. 获取锁
  3. 统计用户已领券的数量
  4. 判断是否超出限领数量
  5. 如果没超，新增一条用户券
  6. 释放锁
  7. 提交事务

注意，这里是先开启事务，再获取锁；而业务执行完毕后，是先释放锁，再提交事务。

假如用户限领数量为1，当前用户没有领过券。但是这个人写了一个抢券程序，用自己的账号并发的来访问我们。

假设此时有两个线程并行执行这段逻辑：

  • 线程1开启事务，然后获取锁成功；线程2开启事务，但是获取锁失败，被阻塞
  • 线程1执行业务，由于没领过，所有业务都能正常执行，不再赘述
  • 线程1释放锁。此时线程2立刻获取锁成功，开始执行业务：
    • 线程2统计用户已领取数量。由于线程1尚未提交事务，此时线程2读取不到未提交数据。因此认为当前用户没有领券。
    • 判断限领数量通过，于是也新增一条券
    • 安全问题发生了！

总结：由于 锁过早释放，导致了事务尚未提交，判断出现错误，最终导致并发安全问题发生。 这其实就是 事务边界和锁边界 的问题。

解决方案很简单，就是调整边界：

  • 业务开始前，先获取锁，再开启事务
  • 业务结束后：先提交事务，再释放锁

对事务外层加锁

		// 4.校验并生成用户券
        synchronized(userId.toString().intern()){ // 这里加锁，这样锁在事务之外
            checkAndCreateUserCoupon(coupon, userId, null);
        }

	@Transactional // 这里进事务，同时，事务方法一定要public修饰
    public void checkAndCreateUserCoupon(Coupon coupon, Long userId, Integer serialNum){
        // 1.校验每人限领数量
        // 1.1.统计当前用户对当前优惠券的已经领取的数量
        Integer count = lambdaQuery()
                .eq(UserCoupon::getUserId, userId)
                .eq(UserCoupon::getCouponId, coupon.getId())
                .count();
        // 1.2.校验限领数量
        if (count != null && count >= coupon.getUserLimit()) {
            throw new BadRequestException("超出领取数量");
        }
        // 2.更新优惠券的已经发放的数量 + 1
        int r = couponMapper.incrIssueNum(coupon.getId());
        if (r == 0) {
            throw new BizIllegalException("优惠券库存不足");
        }
        // 3.新增一个用户券
        saveUserCoupon(coupon, userId);
        // 4.更新兑换码状态
        if (serialNum != null) {
            codeService.lambdaUpdate()
                    .set(ExchangeCode::getUserId, userId)
                    .set(ExchangeCode::getStatus, ExchangeCodeStatus.USED)
                    .eq(ExchangeCode::getId, serialNum)
                    .update();
        }
    }

总结

在事务和锁并行存在时，一定要考虑事务和锁的边界问题。由于事务的隔离级别问题，可能会导致不同事务之间数据不可见，往往会产生一些不可预期的现

到这里就万事大吉了嘛？其实并没有

事务失效问题

虽然解决了并发安全问题，但其实我们的改造却埋下了另一个隐患。一起测试一下。 我们在领券业务的最后 故意抛出一个异常 ：

经过测试，发现虽然抛出了异常，但是库存、用户券都没有回滚！事务失效了！

事务失效的原因有很多，接下来我们就逐一分析一些常见的原因

事务方法非public修饰

由于Spring的事务是基于AOP的方式结合动态代理来实现的。因此事务方法一定要是public的，这样才能便于被Spring做事务的代理和增强。 而且，在Spring内部也会有一个 org.springframework.transaction.interceptor.AbstractFallbackTransactionAttributeSource类，去检查事务方法的修饰符：

@Nullable
 protected TransactionAttribute computeTransactionAttribute(
  Method method, @Nullable Class<?> targetClass) {
   // Don't allow non-public methods, as configured.
   if (allowPublicMethodsOnly() && 
  !Modifier.isPublic(method.getModifiers())) {
      return null;
   }

    // ... 略

   return null;
 }

非事务方法调用事务方法

@Service
public class OrderService {
    
    public void createOrder(){
        // ... 准备订单数据
        
        // 生成订单并扣减库存
        insertOrderAndReduceStock();
    }
    
    @Transactional
    public void insertOrderAndReduceStock(){
        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();
    }
}

可以看到，insertOrderAndReduceStock方法是一个事务方法，肯定会被Spring事务管理。Spring会给OrderService类生成一个动态代理对象，对insertOrderAndReduceStock方法做增加，实现事务效果。

但是现在createOrder方法是一个非事务方法，在其中调用了insertOrderAndReduceStock方法，这个调用其实隐含了一个this.的前缀。也就是说，这里相当于是直接调用原始的OrderService中的普通方法，而非被Spring代理对象的代理方法。那事务肯定就失效了！

事务方法的异常被捕获了

 @Service
 public class OrderService {

    @Transactional
    public void createOrder(){
        // ... 准备订单数据
        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();
    }

    private void reduceStock() {
        try {
            // ...扣库存
        } catch (Exception e) {
            // 处理异常
        }
    }

 }

在这段代码中，reduceStock方法内部直接捕获了Exception类型的异常，也就是说方法执行过程中即便出现了异常也不会向外抛出。 而Spring的事务管理就是要感知业务方法的异常，当捕获到异常后才会回滚事务。 现在事务被捕获，就会导致Spring无法感知事务异常，自然不会回滚，事务就失效了。

事务异常类型不对


	@Service
 public class OrderService {

    @Transactional(rollbackFor = RuntimeException.class)
    public void createOrder() throws IOException {
        // ... 准备订单数据

        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();

        throw new IOException();
    }
 }

Spring的事务管理默认感知的异常类型是RuntimeException，当事务方法内部抛出了一个IOException时，不会被Spring捕获，因此就不会触发事务回滚，事务就失效了。

因此，当我们的业务中会抛出RuntimeException以外的异常时，应该通过@Transactional注解中的rollbackFor属性来指定异常类型：

@Transactional(rollbackFor = Exception.class)

事务传播行为不对

  @Service
 public class OrderService {
    @Transactional
    public void createOrder(){
        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();
        throw new RuntimeException("业务异常");
    }
    @Transactional
    public void insertOrder() {
    }
    @Transactional(propagation = Propagation.REQUIRES_NEW)
    public void reduceStock() {
    }
 }

在示例代码中，事务的入口是createOrder()方法，会开启一个事务，可以成为外部事务。在createOrder()方法内部又调用了insertOrder()方法和reduceStock()方法。这两个都是事务方法。

不过，reduceStock()方法的事务传播行为是REQUIRES_NEW，这会导致 在进入reduceStock()方法时会创建一个新的事务，可以成为子事务 。insertOrder()则是默认，因此会与createOrder()合并事务。

因此，当createOrder方法最后抛出异常时，只会导致insertOrder方法回滚，而不会导致reduceStock方法回滚，因为reduceStock是一个独立事务。

所以，一定要 慎用传播行为，注意外部事务与内部事务之间的关系 。

没有被Spring管理

 
//  @Service
 public class OrderService {
    @Transactional
    public void createOrder(){
        // 生成订单
        insertOrder();
        // 扣减库存
        reduceStock();
        throw new RuntimeException("业务异常");
    }
    @Transactional
    public void insertOrder() {
    }
    @Transactional
    public void reduceStock() {
    }
 }

这个示例属于比较低级的错误，OrderService类没有添加@Service注解，因此就没有被Spring管理。你在方法上添加的@Transactional注解根本不会有人帮你动态代理，事务自然失效。

优化

通过上面分析发现我们的事务失效的原因是什么了：

为了控制事务边界，我们改变了事务注解标记的位置，这就导致了非事务方法调用了事务方法。

那么，有没有办法让这个事务再次生效呢？

答案是有的，既然事务失效的原因是方法内部调用走的是this，而不是代理对象。那我们只要想办法获取代理对象不就可以了嘛。

这里，我们可以借助AspectJ来实现。

  • 1）引入AspectJ依赖：
  • 2）暴露代理对象
    • 在启动类上添加注解，暴露代理对象：
  • 3）使用代理对象

最后，改造领取优惠券的代码，获取代理对象来调用事务方法：

总结

到此还没有结束哦，等待下回分解！

模拟面试

如何解决优惠券的超发问题？

答：超发、超卖问题往往是由于多线程的并发访问导致的。所以解决这个问题的手段就是加锁。可以采用悲观锁，也可以采用乐观锁。
如果并发量不是特别高，就使用悲观锁就可以了。不过性能会受到一定的影响。
如果并发相对较高，对性能有要求，那就可以选择使用乐观锁。
当然，乐观锁也有自己的问题，就是多线程竞争时，失败率比较高的问题。并行访问的N个线程只会有一个线程成功，其它都会失败。
所以，针对这个问题，再结合库存问题的特殊性，我们不一定要是有版本号或者CAS机制实现乐观锁。而是改进为在where条件中加上一个对库存的判断即可。
比如，在where条件中除了优惠券id以外，加上库存必须大于购买数量的条件。这样如果库存不足，where条件不成立，自然也会失败。
这样做借鉴了乐观锁的思想，在线程安全的情况下，保证了并发性能，同时也解决了乐观锁失败率较高的问题，一举多得。

Spring事务失效的情况碰到过吗？或者知不知道哪些情况会导致事务失效？

答：Spring事务失效的原因有很多，比如说：
- 事务方法不是public的
- 非事务方法调用事务方法
- 事务方法的异常被捕获了
- 事务方法抛出异常类型不对
- 事务传播行为使用错误
- Bean没有被Spring管理
等等。。
在我们项目中确实有碰到过，我想一想啊。
我记得是在优惠券业务中，一开始我们的优惠券只有一种领取方式，就是发放后展示在页面，让用户手动领取。领取的过程中有各种校验。那时候没碰到什么问题，项目也都正常运行。
后来产品提出了新的需求，要加一个兑换码兑换优惠券的功能。这个功能开发完以后就发现有时候会出现优惠券发放数量跟实际数量对不上的情况，就是实际发放的券总是比设定的要少。一开始一直找不到原因。
后来发现是某些情况下，在领取失败的时候，扣减的优惠券库存没有回滚导致的，也就是事务没有生效。仔细排查后发现，原来是在实现兑换码兑换优惠券的时候，由于很多业务逻辑跟手动领取优惠券很像，所以就把其中的一些数据库操作抽取为一个公共方法，然后在两个业务中都调用。因为所有数据库操作都在这个共享的方法中嘛，所以就把事务注解放到了抽取的方法上。当时没有注意，这恰好就是在非事务方法中调用了事务方法，导致了事务失效。

在开发中碰到过什么疑难问题，最后是怎么解决的？

比如在开发优惠券功能的时候，优惠券有一个发放数量的限制，也就是库存。还有一个用户限量数量的限制，这个是设置优惠券的时候管理员配置的。
因此我们在用户领取优惠券的时候必须做库存校验、限领数量的校验。由于库存和领取数量都需要先查询统计，再做判断。因此在多线程时可能会发生并发安全问题。
其中库存校验其实是更新数据库中的已经发放的数量，因此可以直接基于乐观锁来解决安全问题。但领取数量不行，因为要临时统计当前用户已经领取了多少券，然后才能做判断。只能是采用悲观锁的方案。但是这样会影响性能。
所以为了提高性能，我们必须减少锁的范围。我们就把统计已经领取数量、判断、新增用户领券记录的这部分代码加锁，而且锁的对象是用户id。这样锁的范围就非常小了，业务的并发能力就有一定的提升。
想法是很好的，但是在实际测试的时候，我们发现尽管加了锁，但是还会出现用户超领的现象。比如限领2张，用户可能会领取3张、4张，甚至更多。也就是说并发安全问题并没有解决。
锁本身经过测试，肯定是没有问题的，所以一开始这个问题确实觉得挺诡异的。后来调试的时候发现，偶然发现，有的时候，当一个线程完成了领取记录的保存，另一个线程在统计领券数量时，依然统计不到这条记录。
这个时候猜测应该是数据库的事务隔离导致的，因为我们领取的整个业务外面加了事务，而加锁的是其中的限领数量校验的部分。因此业务结束时，会先释放锁，然后等整个业务结束，才会提交事务。这就导致在某些情况下，一个线程新增了领券记录，释放了锁；而另一个线程获取锁时，前一个线程事务尚未提交，因此读取不到未提交的领券记录。
为了解决这个问题，我们将事务的范围缩小，保证了事务先提交，再释放锁，最终线程安全问题不再发生了。

评论( 0 )

  • 博主 Mr Cai
  • 坐标 河南 信阳
  • 标签 Java、SpringBoot、消息中间件、Web、Code爱好者

热门文章

标签云

MybatisJVM堆栈抽象工厂模式synchronized / lock适配器模式去重KafkaCASCPU过高排查消息丢失ElasticSearch优化RT(响应时间)组合模式原型模式Redis数据结构号段模式宕机微服务项目架构HashMap单例模式合并写请求开发规范BigDecimal异步建造者模式延时队列工厂模式踩坑

文章目录

    友情链接

    百度