【SpringBoot】Redisson 分布式锁注解和 @Transactional 注解一起使用问题

一、前言

平时使用切面去加分布式锁，是先开启事务还是先尝试获得锁？这两者有啥区别？

业务中怎么控制切面的顺序？切面的顺序对事务的影响怎么避免？

下面程序分析：

    @Override
    @Transactional
    public ReceiveH5ActivityPrizeResponse receive(ReceiveH5ActivityPrizeRequest request) {
        logger.info("xxx:{}", JSON.toJSONString(request));
        ReceiveH5ActivityPrizeResponse response=new ReceiveH5ActivityPrizeResponse();
        String lockName="receiveH5ActivityPrize" + request.getActivityId();
        final DistributeLock lock = jedisLockFactory.getJedisLock(lockName,20, TimeUnit.SECONDS);
        // 1.加锁
        lock.lock();
        try {
            //todo 
            // 2 业务逻辑 先判断是否存在，不存在插入一条数据，存在返回(不插入)
        } finally {
            // 3.释放锁
            lock.unLock();
        }
        // 4 返回
        return response;
    }

分布式锁失效并不是真正的失效，只是读到数据，读取的数据库数据不是最新的。

@Transactional 注解在执行该方法时开启一个事物，当执行到3步时，insert 事物务还未提交，因此其它线程进入分布式锁代码块后，继续会执行2操作，发现数据不存在继续插入一条新数据，存在两条记录，此时数据就会出现 bug 问题。

解决办法：先加锁，然后在开启事物，可以保证安全性。 

二、普通未指定 order 的切面和 @Transactional 的先后顺序

        先说下为啥会考虑到这个，我们可以知道 @Transaction 一般加在具体要执行业务的service 方法上，那如果我要进行并发控制对业务进行加锁，那么尝试锁和开启事务孰先孰后呢？

    @Override
    @Transactional
    @RedisLock(key = Constant.FANLI_GRANT_VIP_LOCK, param = "#vipOrderNo")
    public void grantGdVip(String vipOrderNo) {
        // 业务逻辑
    }

        按照业务流程上来看我们需要先尝试锁后开启事务，因为没获得锁开启事务需要和数据库进行交互开启一个新的事务，平常对业务结果是不会影响的，但是当高并发时是会对数据库带来不小压力。

总结：

        如果普通切面没指定 order 会比 transaction 后执行。当锁或者一些检查性切面被使用时如果条件不满足不能进入业务也会导致事务的开启产生了不必要的消耗，当并发高时尤为明显。

三、切面的顺序对事务的影响怎么避免？

其实避免方式有三种，一种是指定order，一种是把自定义切面移到更外层中，一种是使用编程式事务。

1、指定 Order

@Aspect
@Component
@Slf4j
@Order(1)
public class LockAspect {

}

2、移到最外层中

移到更外层中就不用证明了，调用的自然顺序，比如放在Controller的方法上。

    @PostMapping("/web/cardb/gift/receive")
    @ApiOperation("B卡赠品领取接口")
    @TokenAuthentication
    @RedisLock(key = LockKey.RECEIVE_CARD_B_GIFT, param = "#userInfo.userId")
    public ApiResultResponse receiveCardBGift(@RequestBody @Valid CardbReceiveGiftRequest request) {
    // 代码
}

3、使用编程式事务

 当然可以，调用的自然顺序，事务的开启更加现式。

四、总结

因为声明式事务比较好用，生产中使用的比较多，只有为了控制事务粒度或者不需要抽出一个新的类（为了使事务生效）才会使用编程式事务。

所以更加倾向于移到更外层，因为指定 order 的前提是你知道事务切面的和不指定order普通切面的顺序，同时一旦切面变多比如有统一加锁切面、统一检查是否认证切面等需要控制自定义切面顺序容易和事务切面搞混，不利于维护，这个也相当于自定义切面和框架前面隔离。这也从一个侧面证明了校验放 controller 的合理性。

五、参考文档

@Transactional和普通自定义切面执行顺序的思考