代码中使用redis锁和Spring事务时需注意的点

  前几天，有同事过来请教，为啥明明加了redis锁，也有在代码里做了插入的幂等校验，同一个入参并发时为啥还是插入了两条。

  首先，这种重复性的数据可以在数据库用唯一索引做。但这不是我们此次讨论的重点。我们需要讨论的是，为啥redis锁不起作用了。

  review了代码，发现他的redis锁用了注解AOP进行实现。并且在方法上也用了@Transactional事务注解。所以这是个对AOP的执行顺序和事务的理解不到位的问题。(代码中注册时会判断手机号是否已注册)

  

 

  我们知道，在事务未提交前，对其他事务的读是不可见的，否则就会发生未提交读，即脏读的情况出现。

  我们假设现在有两个请求A、B同时发起。A获取到redis锁，并执行完，释放了redis锁，但是此时事务未提交。由于A释放了锁，B就可以获取到redis锁并进入方法。

  在这种情况，就是因为A事务未提交，但redis锁已经释放，另一个B请求又可以进入该方法。进入该方法后，首先走手机号是否在数据库已存在判断。那么由于A事务未提交，那么B查询的时候，手机号就是未注册的，就可以继续走注册逻辑插入会员信息。

  DEBUG了一下，我们可以看到Redis锁AOP和Spring事务AOP的执行顺序（优先级）。

 

  LockAspectHandler是Redis锁，TransactionAspectSupport是事务AOP，那么从调用栈我们可以看出redis锁在事务前面，也就是redis会先释放，后才是事务提交。那么就印证了我们前面的推断。（事务的切面优先级高于redis）

  

  告知同事可以在切面类上实现Order接口，并重写getOrder方法，order值越小则优先级越高。

 

  将redis锁切面优先级提到事务前，问题解决。

  重点就是要让事务先提交，再释放redis锁。