Redisson+事务=失效的场景

1、失效场景1

假设有这样一个需求：创建付款单，要求不能重复创建相同业务单号的付款单。为了保证幂等，我们需要判断数据库中是否已经存在相同业务单号的付款单，并且需要加锁处理并发安全性问题。

@Transactional
public void createPaymentOrderInnerLock(PaymentOrder paymentOrder){
    RLock lock = redissonClient.getLock(paymentOrder.getBizNo());
    //采用的redisson可重入锁，提供watchdog机制，在锁释放前默认每10s重置锁失效时间为30s
    lock.lock();
    try {
        LambdaQueryWrapper<PaymentOrder> paymentOrderLambdaQueryWrapper = new LambdaQueryWrapper<>();
        paymentOrderLambdaQueryWrapper.eq(PaymentOrder::getBizNo,paymentOrder.getBizNo());
        //判断数据库中是否存在相同业务单号的付款单
        long count = this.count(paymentOrderLambdaQueryWrapper);
        //存在相同业务单号的付款单则抛异常
        if(count>0){
            throw new RuntimeException("不可重复提交付款单");
        }else{
            //无重复数据，创建付款单
            this.save(paymentOrder);
            //其他DB操作
            ...
        }
    } finally {
            // 释放锁
            if (lock.isLocked() && lock.isHeldByCurrentThread()) {
                lock.unlock();
            }
    }
}

上述问题分析图如下：

解决方案：

为了避免锁在事务提交前释放，我们应该在事务外层使用锁。

• 方式一：在Controller层用Redisson，而不是在Service层用Redisson。
• 方式二：在Service层用Redisson，不用声明式事务，而采用编程式事务（最小范围控制事务）。

2、失效场景2

业务未执行完，锁超时释放

@Override
public void createPaymentOrderRenault(List<PaymentOrder> paymentOrderList){
    if(!CollectionUtils.isEmpty(paymentOrderList)){
        for (PaymentOrder paymentOrder : paymentOrderList) {
            /**
             * 采用公司框架提供的分布式锁
             * 10---等待锁释放时间
             * 1---尝试获取锁时间间隔
             * 5---锁失效时间
             * 注意：此处设置锁失效时间为5秒，在createPaymentOrderNoLock中睡眠5秒模拟耗时操作，此时会出现业务未执行完，锁超时释放的问题
             */
            try (AutoReleaseLock lock = acquireLock(paymentOrder.getBizNo(),  10, 1, 5, TimeUnit.SECONDS)) {
                if(lock != null) {
                    paymentOrderService.createPaymentOrderNoLock(paymentOrder);
                } else {
                    log.info("未获取到锁！");
                }
            }catch (CacheParamException e) {
                log.info("获取锁失败");
            }
        }
    }
}


@Override
@Transactional
public void createPaymentOrderNoLock(PaymentOrder paymentOrder) {
    LambdaQueryWrapper<PaymentOrder> paymentOrderLambdaQueryWrapper = new LambdaQueryWrapper<>();
    paymentOrderLambdaQueryWrapper.eq(PaymentOrder::getBizNo,paymentOrder.getBizNo());
    long count = this.count(paymentOrderLambdaQueryWrapper);
    if(count>0){
        log.info("不可重复提交付款单");
        throw new RuntimeException("不可重复提交付款单");
    }else{
        this.save(paymentOrder);
        //模拟耗时操作...
        try {
            Thread.sleep(5000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

问题分析：

出现上述问题是因为在指定的锁的失效时间内（并且没有续命机制），锁内部的业务代码没有执行完，锁超时释放了。尤其我们财务端处于业务链下游，处理的数据量一般都比较大，交互的端比较多，尤其要注意这种情况。下列情形都有可能出现代码没有执行完，锁超时释放的问题。

• 锁的失效时间设置的太短
• 锁的粒度太大，处理链路冗长
• 锁内部包含很多耗时操作，比如远程调用、大数据量处理等

解决方案：

首先会想到，把失效时间设置长一点，确实可以。但设置多长合适呢，设置过长有可能存在拿到锁的客户端宕掉了，此时就要等锁过期才能释放，其他节点处于阻塞状态，降低了系统吞吐。又或者预估了一个失效时间在项目初期没问题，随着数据量增多，或者其他一些不确定因素造成了超时，也会出现问题。

可以采用类似Redisson的watchdog机制给锁续命。另外，注意减小锁的粒度，把存在并发安全性问题的关键代码锁住即可，增加系统吞吐量。同时也要注意减小事务的粒度，把查询操作、甚至一些远程调用放到事务外部（注意读写分离的情况），避免出现大事务问题。