序列号生成并发引发的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。
  • redisson锁，由于恰好有用redis，后期都统一改成的了用此锁替代上述方法了。
  • 还有后续，即便用redis锁，由于牵扯到事务，和synchronized基本一样，还是要加Propagation.REQUIRES_NEW（否则需要将锁加到事务最上层，每个涉及到调用这个序列号方法的都要再套一层方法，非常繁琐，而且多人协作很多人就直接调用了，可能并不会注意到锁的问题，太容易出错），这样就导致万一上级事务生效，但是获取序列号反而生效就会导致下次再获取序列号就缺少不连续了，从而引发业务问题，缺少的序列号分不清是删除了还是一开始就没生成。最终由于业务量不大，改成了数据库悲观锁for update了。
posted @ 2023-02-23 09:47  漫游云巅  阅读(214)  评论(0)  编辑  收藏  举报