分布式锁和spring事务管理

最近开发一个小程序遇到一个需求需要实现分布式事务管理

业务需求

用户在使用小程序的过程中可以查看景点,对景点地区或者城市标记是否想去,那么需要统计一个地点被标记的人数,以及记录某个用户对某个地点是否标记为想去,用两个表存储数据,一个地点表记录改地点被标记的次数,一个用户意向表记录某个用户对某个地点是否标记为想去。由于可能有多个用户同时标记一个地点,每个用户在前端点击想去按钮之后,后台接收到请求,从数据库查询某个城市的标记人数,再加1,然后更新到数据库。从数据库查询标记人数,再加1,然后更新到数据库这个过程数据库数据必须加锁,一次只能一个进程处理。否则数据会出现不同步问题

我使用的RedLock做分布式锁管理,用spring注解事务管理。
在实现过程中遇到如下两个映像深刻的问题:
1、分布式锁与spring注解事务共用产生的问题
2、锁在事务提交前超时问题

使用分布式锁RedLock及spring事务实现

最初实现代码如下:

 public markScenicSpot(){
  //设置锁为destId
   RLock lock = redisson.getLock("Afanti_markScenicSpot_updateCountwantAndCountbeenLock_" + ID);
   //尝试获取锁
   long lockTimeOut = 30; //持有锁超时时间
   **boolean success = lock.tryLock(5, lockTimeOut, TimeUnit.SECONDS);**
   if (success) {
      try {
          //业务逻辑实现
      }catch (Exception e){
          throw e;
      } finally{
          //释放锁
          **lock.unlock();**
      }
   } else {
       log.error("获取锁失败!更新失败!");
       throw new BizException(ErrorCodeEnum.PROCESS_DATA_ERROR);
   }
 }

问题:高并发是锁没有生效

1、spring注解事务@Transactional和分布式锁不能一起使用
这是因为@Transactional是通过方法是否抛出异常来判断事务是否回滚还是提交,此时方法已经结束。但是我们必须在方法结束之前释放锁,
因此在释放锁之后,此时还没提交,由于锁已经释放,其他进程可以获得锁,并从数据库查询地点标记数,但是此时前一个进程没有提交数据。该进程查到的数据不是最新的数据。
这个问题我排查的时候花了很久,因为锁释放和提交事务之间只要几毫秒的时间,之前一直以为这么短的时间不可能是这里的问题,有怀疑过但是自己又放弃了
尽管这个过程只要很短的时间(我实际测试过程中这个过程只要几毫秒),但是高并发的情况还是会出问题。

解决1:

由于不能使用注解事务,我改为手动事务管理,增加如下代码。

 public markScenicSpot(){
   //设置锁为destId
   RLock lock = redisson.getLock("Afanti_markScenicSpot_updateCountwantAndCountbeenLock_" + ID);
   //尝试获取锁
   long lockTimeOut = 30; //持有锁超时时间
   boolean success = lock.tryLock(5, lockTimeOut, TimeUnit.SECONDS);
   if(success){
      **DefaultTransactionDefinition def = new DefaultTransactionDefinition();
      def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); // 事物隔离级别
      TransactionStatus status = transactionManager.getTransaction(def); // 获得事务状态**
      try {
          //业务逻辑实现
          //......
          **//提交事务
          transactionManager.commit(status);**
      }catch (Exception e){
          **//回滚事务
          transactionManager.rollback(status);**
      } finally{
          //释放锁
          lock.unlock();
      }
   } else {
       log.error("获取锁失败!更新失败!");
       throw new BizException(ErrorCodeEnum.PROCESS_DATA_ERROR);
   }
 }

问题:锁超时事物异常

1、锁超时问题
在进行手动事务管理之后,解决的同步问题。但是出现另外一个问题,锁超时但是事务仍未提交。由于此时当前进程锁超时但是没有提交,此时其他进程可以获得锁并从数据库查询目的地标记数,但是不是更新之后的数据,取得的数据有误。

解决2:

针对锁超时的情况,只需要当前进程提交之前增加一个判断,判断是否超时,如果超时抛出异常退出即可。
增加如下代码:

public markScenicSpot(){
   //设置锁为destId
   RLock lock = redisson.getLock("Afanti_markScenicSpot_updateCountwantAndCountbeenLock_" + ID);
   //尝试获取锁
   long lockTimeOut = 30; //持有锁超时时间
   boolean success = lock.tryLock(5, lockTimeOut, TimeUnit.SECONDS);
   **//获取锁时间
   long getLockTime=System.currentTimeMillis();**
   if(success){
      //事务管理
      DefaultTransactionDefinition def = new DefaultTransactionDefinition();
      def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); // 事物隔离级别
      TransactionStatus status = transactionManager.getTransaction(def); // 获得事务状态
      try {
          //业务逻辑实现
          //......
          //提交事务,判断锁是否超时
          **if(System.currentTimeMillis()-getLockTime

分布式锁的问题

上面使用的通过时间判断锁是否超时的方案,其实是不完全正确的,但是大部分时间可用。
下面我们来分析一下出问题的情况:
分布式锁和spring事务管理_第1张图片

  • Client1获取锁成功,执行逻辑后,判断锁没有超时,但是此时还没有提交事务发生FGC,之后锁超时
  • Client2在锁超时后获得锁,执行逻辑并写入数据
  • Client1 FGC完成,提交事务写入数据,覆盖了Client2的写入

由于存在GC,所以可能在任意时间内发生FGC,导致程序暂停锁超时,但是程序不知道继续提交事务。
那么这个问题如何解决呢?

使用数据库乐观锁可以解决这个问题

总结

高并发情况下,分布式事务很容易出问题,要对各种情况分析是否可能出问题,并要对所有可能出问题的情况做充分的测试才能保证程序健壮。

RedLock算法并不是一个严谨的算法,有一些问题,使用的时候要了解他的特性。关于RedLock算法有一个Martin和算法作者antirez的争论,请看我的另一篇文章 关于RedLock分布式锁大佬的争论

你可能感兴趣的:(锁及事务,分布式,spring,java)