序列号生成并发引发的synchronized、数据库隔离级别、myabits缓存等一些问题记录

起因

• 一个序列号产生方法发现有并发问题。
• 修改这个方法中发生了一些错误，而这涉及到了一些的知识点，所以记录下。

涉及点

• synchronized方法：如果此方法内包含数据库操作，且外围有事务时，并不能完全锁住。
• 数据库隔离级别
  • RC-不可重复读，也就是在同一个事务中，多次select同一条sql获取的结果可能不同。
  • RR-可重复度，同一个事务中，多次select同一条sql获取的结果相同，除非中间update进行了数据修改。
  • mysql的默认隔离级别是RR，其它的数据库一般默认级别是RC。
• mybatis缓存，在有事务的情况下，多次select同一个sql，第二次将不再请求数据库，而是直接从缓存读取。

描述

情景一

• 类似的代码如下，下发的代码在并发时就会出现重复的code：

  public Integer getCode(){
      CodeRule codeRuleInfo = selectCodeRuleInfo();//1、从数据库获取当前的记录
      Integer newCode = codeRuleInfo.getCurrentCode() + 1;//当前code+1
      codeRuleInfo.setCode(newCode);//2、赋值最新的
      updateCodeRule(codeRuleInfo);//3、更新数据库
      return newCode;
  }
  

• 由于是单机环境，最开始就想用synchronized解决，但发现getCode本身是在一个事务下的，这样就导致仅仅靠synchronized并不能锁住，原因如下：

  1-事务开始 -> 2-synchronized开始 -> 3-synchronized结束 -> 4-事务提交
  

  其中3和4之间会又时间差，导致这期间如果有并发进来，还是会出现重复，所以需要改成：

  1-synchronized开始 -> 2-事务开始 -> 3-事务提交 -> 4-synchronized结束
  

• 正常的改进应该是：

  //原有方法，增加synchronized锁
  public synchronized Integer getCode(){
      return AAA.getCode();
  }
  //另一个类中AAA，开启新事务
  @Transactional(propagation = Propagation.REQUIRES_NEW)
  public Integer getCode(){
      CodeRule codeRuleInfo = selectCodeRuleInfo();
      Integer newCode = codeRuleInfo.getCurrentCode() + 1;//当前code+1
      codeRuleInfo.setCode(newCode);
      updateCodeRule(codeRuleInfo);
      return newCode;
  }
  

情景二

• 当时改的时候脑子抽了，并没有按照上方的改，而是改成这样了：

  //原有方法，增加synchronized锁
  public synchronized Integer getCode(){
      CodeRule codeRuleInfo = selectCodeRuleInfo();
      Integer newCode = codeRuleInfo.getCurrentCode() + 1;//当前code+1
      codeRuleInfo.setCode(newCode);
      AAA.updateCodeRule(codeRuleInfo);//只把更新放到了新事务中
      return newCode;
  }
  //另一个类中AAA，开启新事务
  @Transactional(propagation = Propagation.REQUIRES_NEW)
  public Integer updateCodeRule(){
      //执行sql更新
  }
  

• 上述方法就导致一个问题，select方法在主事务中，而update方法在新事务中，部署到线上果然不但没解决，反而非并发仅仅是循环中就全部重复了，原因如下：

  • mysql默认的隔离级别是RR，也就是同一个事务内多次select同一个语句，获取的结果都是一样的，除非两个select之间有update操作才会重新获取最新数据。但我们的update方法放在了新的事务中，导致并没有对select产生影响，所以循环下的getCode就会产生重复数据。

• 但是诡异的是，我们在部署前有作过简单的测试，测试是正常递增的，找了半天才发现是mybatis缓存的原因：

  • mybatis一级缓存会对多次相同的sql查询进行缓存，第二次就不会再读取数据库了，而是直接从缓存中获取，除非中间进行了数据库的增删改，而新事务中增删改同样不影响缓存清除，听起来和数据库的RR隔离级别很像，但这里有个本质区别，它缓存的是一个对象，如果你对这个对象中的数据进行了修改，那么下次获取的是修改后的数据，而我们代码中每次都有codeRuleInfo.setCode(newCode);来对此对象进行了修改，所以在mybatis缓存的作用下，取出的数据却是正常递增的。

• 这样就又不对了，照理来说如果按照mybatis缓存，那正式环境也不应该会重复，再进一步的排查，原因如下：

  • 我们测试环境中的很简单，就一个select和一个update，但我们正式环境中getCode仅仅是一个主事务中的一个小方法，在循环中getCode后面还有一些其它表的增删改操作，而这些增删改会清空mybatis的缓存。
  • 这里我们有一个误区，原以为mybatis缓存也是仅仅只有针对该表的增删改才会清除缓存，但实际上是针对任意表的增删改都会清除缓存，所以我们线上环境是每次都会清缓存从数据库读取，然后就是数据库RR隔离级别导致数据重复，而本地测试则是走缓存，正常增加。

更好的并发处理

• 这种涉及到数据库又存在事务的，采用synchronized方法还是有些缺陷的：子事务独立于主事务，如果子事务出问题，则不能整体回滚了。感觉更应该考虑用数据库的悲观锁和乐观锁来解决，或者是参考微服务的一些锁实现。
• 悲观锁实现比较简单点，在并发不高时可以考虑，在select 语句中加上for update，但需要注意的是在RR隔离环境下，如果select没有命中数据，可能会产生间隙锁（很复杂，不同主键、索引、非索引造成的锁类型各不相同，可自行搜索相关资料），此时又insert就可能会造成死锁。解决方法是设置数据库隔离级别为RC，因为RC模式下不会有间隙锁产生，从而不会死锁。
• mysql数据库设置成RC隔离级别也没什么问题，毕竟Oracle、PostgreSQL等一大众数据库的默认级别就是RC，而阿里云等一些云厂商的RDS数据库隔离级别默认也是RC。