分布式锁与Spring事务共用产生“冲突”的解决方案 ☞ （篇幅较长，看完绝对有收获）

最新推荐文章于 2024-05-16 14:01:56 发布

长庚~Richarlie

最新推荐文章于 2024-05-16 14:01:56 发布

阅读量2k

点赞数 5

文章标签： spring 分布式 mybatis

原文链接：https://blog.csdn.net/Appleyk/article/details/113652938

版权

1、大纲要点

spring-framework5.2.x （我的fork版）gitee地址：https://gitee.com/appleyk/spring-framework/tree/5.2.x/

分布式锁springboot项目github地址：https://github.com/kobeyk/springboot-distribute-lock-sample

分布式锁springboot项目gitee地址：https://gitee.com/appleyk/springboot-distribute-lock-sample

1.1 场景：以最常见的XXX商品下单（减库存）为例，如何在高并发的互联网环境下，避免出现“超卖”的问题？

1.2 解决方案：加锁，准确点，分布式锁

1.3 锁技术选型：

1.3.1 基于数据库层面的“乐观”和“悲观”锁

1.3.2 基于redisson框架的分布式锁

redis可视化工具

链接：https://pan.baidu.com/s/1KWeBEDQicTNkF9TT6e00Kg 提取码：k4zn

1.3.3 基于zookeeper分布式协调器的分布式锁

ZooInspector可视化工具（jar包）

链接：https://pan.baidu.com/s/1rMQNSJp975xMvS1X0ejKBw 提取码：0988

1.4 数据库：postgresql、mysql8

1.5 ORM框架选型：mybatis-plus、tk.mybatis、jpa

1.6 数据库连接工具：

1.6.1 DataGrip 2020

链接：https://pan.baidu.com/s/1FTz21gPJj73LRV-HPe5sFQ *提取码：troo***

1.6.2 Navicat

1.7 并发测试工具：jmeter

链接：https://pan.baidu.com/s/1ZjHNcKIpIY-lbkshlNzfFg 提取码：vel3

1.8 测试出现的问题：锁的释放在事务提交成功之前完成

1.8.1 导致的后果：锁白加了，浪费了性能不说，最后还没能挡住商品的“超卖”

1.8.2 解决方案调整：

1、第一种解决方案：service方法上不加事务注解，在具体的reduce（repo）方法上加事务注解

2、第二种解决方案：使用事务同步管理器，约束释放锁的时机必须在事务完成后才可以

3、第三种解决方案：service方法上不加@Transaction，在程序中，手动管理事务的提交和回滚

4、第四种解决方案：压根就不加锁，由上层进行锁控制

2、为什么要使用分布式锁

（1）单机应用无法满足互联网三高（高并发、高性能、高可用），所以需要对应用进行拆分，必然牵扯服务集群部署

（2）一旦集群部署，就牵扯到多线程并发下，对同一资源的操作，如果仍然使用单机场景下的JVM锁，会有问题，因此不得不考虑采用分布式锁来实现并发情况下，数据共享状态下线程操作结果的一致性

举例：拿最常见的商品下单来说，如果存在同一时刻，购买同一商品的人数激增，假如有1000人同时购买，但实际上库存中的商品仅剩下500件。这种业务场景就属于多线程操作同一共享变量：多线程就是同一时刻的N多用户点击下单按钮发出的请求，共享变量就是同一件商品的库存量，而操作就是用户下单导致的商品减库存。有点多线程编程经验的都知道，这种情况如果不针对业务场景做出点demo改变，减库存的结果必然是不安全的，比如库存出现负数，导致“超卖”问题的发生。

消除多线程不安全问题的做法大体有两种：

1、干掉共享变量

这个不太现实，但是干掉共享变量有两种思路可以提供

（1）使用final来修饰变量，定义变量一开始就赋值，后续无法再进行赋值操作（这种多线程下必然是安全的），这种适合读做常量，不适应读写（不仅读，还要改）的业务场景。

（2）使用ThreadLocal，为共享变量在每一个线程中保存一个副本，即线程操作的都是自己的变量副本，所以不会再出现多线程同时操作同一变量的情况了。但是ThreadLocal这种不适用本篇提到的业务场景，一是它是基于单机JVM的，微服务多JVM下是无法搞的，二是我们每个线程对变量副本操作完之后，最后的业务处理是要对变量进行统一更新的，ThreadLocal更多的作用是对全局共享变量起到一个隔离的作用，比如其在Spring事务管理器中的应用，比如其在Mybaits3数据库会话管理器中的应用：

如在Spring事务同步管理器（TransactionSynchronizationManager）中的应用：

这个类是一个抽象类，有一堆的静态常量（NamedThreadLocal类型）和方法，如下

NamedThreadLocal继承ThreadLocal，可以给变量起个名字

什么获取资源、绑定资源、解绑资源等

那么这个类中的这些方法是在什么时候调用的呢，请继续往下看…

Sprinig事务管理器实现的标记接口，也是顶层接口，通常标记接口时没有任何方法定义的，比如克隆和序列化接口等

其实现/继承的类视图（部分）如下（主要看Jpa事务管理器）：

由于本篇演示案例是在spring-framework5.2.x源码中进行调试的，而orm用的是spring-data-jpa依赖包，因此d事务管理器接口的最终实现子类是JpaTransactionManager，在d该类中，我们定位到方法doBegin(…)上（该方法在调用相关带有@Transactional注解的方法时会进入）

点进去定位到下面这一行

我们继续跟进bindResource(…)方法

我们接着点开set(map)方法进行跟踪

有绑定必然有解绑，不然占着资源可还行？

关于ThreadLocal，这里我还要在补充一下，看下图

由于本篇不是重点讲Spring事务工作原理的，所以下面就不再继续了，大家只要知道Spring事务管理器中用到了ThreadLocal就算有收获了

如在Mybatis3的SqlSessionManager中的应用：

除了ThreadLocal的使用，你还会意外发现，这个类的构造器是private的，也就是外界不能直接new，而只能通过该类的静态方法newInstance去实例化

ThreadLocal的get方法这里就不多说了

都讲到这里了，我们来重点看下commit方法的执行过程吧，如下：

其会调用DefaultSqlSessionle类中的commit方法，该方法又调用了commit(boolean force)方法

然后我们进入isCommitOrRollbackRequired方法看一下它的实现，如下：

基于以上分析，如果sql执行的是update操作的话，isCommitOrRollbackRequired(false)的值就是true，继续跟进如下：

事务提交后，再将dirty设置为false

关于ThreadLocal在框架级别项目中的应用，就不多说了（其实是说的有点多了，都跑偏了），奉劝各位，多下源码，多阅读多调试，时间久了，你就会感叹：卧槽，别人写的代码就是牛逼啊！

2、对操作，也就是减库存上锁，而上锁又可以分为两种

（1）JVM锁：如果系统用户量不大，且业务不复杂，不涉及服务拆分，单服务实例即可支撑每日的访问量的话，则在减库存的业务上加JVM锁即可，比如synchronize加在方法或代码块上，比如，具体的方法中，使用JUC并发包下面的lock即可。

（2）分布式锁：如果系统用户量大，且业务需要进行拆分，以微服务的方式多节点部署的话，此时如果仍采用JVM锁的话，就会导致同一共享资源的锁出现“分身”的情况：比如节点A、B、C…上都有一把资源的锁，那还搞个锤子哦。这就好比，明明一个厕所坑位只有一个门，你却设计了三个门，那这个坑位到底是一次只能一个人（线程）进来，还是三个人（线程）都可以进来？因此，分布式服务必须要用分布式锁来解决多线程下共享资源安全的问题！！！

3、分布式锁满足的条件

（1）在分布式环境下，同一时间，一个方法（称作资源比较好，比如sentinel的资源保护机制）只能被一个机器的一个线程执行

（2）高可用的锁获取和锁释放 – 不能这边刚获取到锁，提供锁的应用就挂掉了

（3）高性能的锁获取和锁释放 – 不能获取锁和释放锁比应用方法执行还要费时间吧？

（4）具备可重入特性，线程再次进入方法时，如果持有了资源的锁，则直接进入，但是释放的时候，有几把锁就要释放几次

（5）具备锁失效机制，防止死锁 – 比如redis的key锁，一旦客户端挂掉，如果先前客户端线程持有的锁没有正常释放的话，就会产生死锁，因此需要设置key锁的有效期，再比如zk的临时顺序节点，如果客户端没有正常delete节点，则由zk服务端自动删除

（6）具备非阻塞锁特性，既没有获取到锁后立即返回获取锁失败的状态 – 可以while自旋，直到获取锁成功，但是这种办法会消耗cpu，还有一种就是像zk那样，注册一个顺序节点的监听器，一旦节点删除后，便通知排在该节点后面的节点，以此成功获取锁

3、分布式锁实现的技术方案有哪些

常用到的有三种，分别是基于db、redis和zk，具体如下：

3.1 基于db的锁实现

db采用的orm框架是在mybatis框架的基础上增强的mybatis-plus，数据库则采用的是PostgreSql

由于篇幅有限，只举其中一个例子作为测试，如拿不加锁的和基于资源插入的测试进行比较

1》不加锁的代码片段如下

2》基于资源插入“锁”的代码片段如下：

3.1.1 不加锁，裸奔 – 测试

数据准备，Mac电脑初始库存量为500

jmeter进行并发测试

最终聚合报告如下（当然最终的吞吐量是个大概，可能执行的值是不一样的，具体以生产环境为主）

我们看下数据库中最终的库存量是不是等于0？

3.1.2 基于资源插入，多线程争抢 – 测试

将库存量重置为500，如下：

新增资源表（项目中src目录下，有基于mysql和postgresql的表脚本）如下：

再次jmeter并发测试（还是2s产生2000个线程），执行的聚合结果报告如下：

我们再看下数据库中的商品库存量是否为0？

我们看下控制台打印的结果：

有一个点需要注意，那就是减完库存后，一定要对资源进行delete

如果不删除的话，只会有一个线程成功的获取锁（插入资源），其他线程只能获取失败（再插入通用的资源，会出现唯一性约束的db异常）

比如，我们这样做

重复上述的测试，最终结果你会发现

3.2 基于redisson框架的分布式锁实现

orm采用的是jpa，数据库采用的是双驱动，即postgresql和mysql进行配置切换（目的是对比两者的读写性能）

3.2.1 使用分布式RLock的代码片段

话不多，直接上jmeter测试结果

postgresql：

mysql：

我丢？ postgresql和mysql的并发测试结果居然不一样？postgresql经过几轮测试始终能保证库存量最终为0 ，而mysql无论经过多少次测试，库存量始终不等于0！！！

3.2.2 基于分布式锁与事务共用的思考

其实网上随便搜下，就会出来很多几乎一模一样的文章，那就是关于分布式锁与Spring事务一起用时会导致锁失效的问题，为什么会这样呢，我们看下代码中我们是在什么时候释放锁的

总结一点就是：finally块中的代码，是在return执行之后，return返回之前执行，也就是中间的空档期，就看是锁释放的效率快啊，还是事务执行的效率快了。从并发测试的结果（吞吐量和结果的一致性）来看，postgresql的读写性能要高于mysql，而且postgresql事务执行的效率要优于分布式锁释放的效率（猜测），因此postgresql数据库在并发测试时，库存量始终为0（当然，可能是巧合，还是得大量测试才更有说服力），而mysql就不同了，无论怎么测试，结果都是“惊人”的相似，那就是商品“超卖”了！！！！！！

3.2.3 基于分布式锁与事务共用的思考

基于上述的测试结果，我决定在spring-framework中进行一个demo测试，测试模块是基于gradle构建的，其中build.gradle内容如下

apply plugin: 'idea'



apply plugin: 'war' // 引入war插件, 它默认包含java插件



apply plugin: 'com.bmuschko.tomcat' //tomcat: 插件



 



group 'org.springframework'



version '5.2.7.BUILD-SNAPSHOT'



 



// tomcat: 以下配置会在第一次启动时下载插件二进制文件



buildscript {



    repositories {



        jcenter()



    }



    dependencies {



        classpath 'com.bmuschko:gradle-tomcat-plugin:2.5'



    }



}



 



repositories {



    mavenCentral()



}



 



dependencies {



    compile(project(":spring-context"))



    compile(project(":spring-orm"))



    compile(project(":spring-webmvc"))



    // https://mvnrepository.com/artifact/org.springframework.data/spring-data-jpa



    compile (group: 'org.springframework.data', name: 'spring-data-jpa', version: '2.4.0'){



        // 排除对org.springframework的依赖，用本项目里自带的源码级别的模块



        exclude module: 'spring-tx'



        exclude module: 'spring-context'



        exclude module: 'spring-core'



        exclude module: 'spring-beans'



        exclude module: 'spring-aop'



        exclude module: 'spring-orm'



    }



    // https://mvnrepository.com/artifact/org.redisson/redisson



    compile group: 'org.redisson', name: 'redisson', version: '3.13.6'



    // https://mvnrepository.com/artifact/javax.persistence/javax.persistence-api



    compile group: 'javax.persistence', name: 'javax.persistence-api', version: '2.2'



    // https://mvnrepository.com/artifact/com.alibaba/druid



    compile group: 'com.alibaba', name: 'druid', version: '1.2.4'



    // https://mvnrepository.com/artifact/org.hibernate/hibernate-entitymanager



    compile group: 'org.hibernate', name: 'hibernate-entitymanager', version: '5.4.25.Final'



    // https://mvnrepository.com/artifact/mysql/mysql-connector-java



    compile group: 'mysql', name: 'mysql-connector-java', version: '8.0.21'



    // https://mvnrepository.com/artifact/org.postgresql/postgresql



    compile group: 'org.postgresql', name: 'postgresql', version: '42.2.5'



    // https://mvnrepository.com/artifact/com.fasterxml.jackson.core/jackson-databind



    compile group: 'com.fasterxml.jackson.core', name: 'jackson-databind', version: '2.11.0'



    // https://mvnrepository.com/artifact/org.slf4j/slf4j-simple



    compile group: 'org.slf4j', name: 'slf4j-simple', version: '1.7.30'



    testCompile group: 'junit', name: 'junit', version: '4.12'



    // https://mvnrepository.com/artifact/javax.servlet/javax.servlet-api



    providedCompile group: 'javax.servlet', name: 'javax.servlet-api', version: '4.0.1'



 



    def tomcatVersion = '8.5.16'



    tomcat "org.apache.tomcat.embed:tomcat-embed-core:${tomcatVersion}",



            "org.apache.tomcat.embed:tomcat-embed-logging-juli:8.5.2",



            "org.apache.tomcat.embed:tomcat-embed-jasper:${tomcatVersion}"



}



 



// tomcat参数配置



tomcat{



    httpProtocol = 'org.apache.coyote.http11.Http11Nio2Protocol'



    ajpProtocol  = 'org.apache.coyote.ajp.AjpNio2Protocol'



    httpPort = 8088



}



 



tomcatRun.contextPath = '/'



tomcatRunWar.contextPath = '/'



 



// UTF-8



tasks.withType(JavaCompile) {



    options.encoding = "UTF-8"



}



 



tasks.withType(JavaCompile) {



    // Try to turn them all off automatically



    options.compilerArgs << '-Xlint:none'



    options.compilerArgs << '-nowarn' // same as '-Xlint:none'



 



    // Turn them off manually



    options.compilerArgs << '-Xlint:-auxiliaryclass'



    options.compilerArgs << '-Xlint:-cast'



    options.compilerArgs << '-Xlint:-classfile'



    options.compilerArgs << '-Xlint:-deprecation'



    options.compilerArgs << '-Xlint:-dep-ann'



    options.compilerArgs << '-Xlint:-divzero'



    options.compilerArgs << '-Xlint:-empty'



    options.compilerArgs << '-Xlint:-fallthrough'



    options.compilerArgs << '-Xlint:-finally'



    options.compilerArgs << '-Xlint:-options'



    options.compilerArgs << '-Xlint:-overloads'



    options.compilerArgs << '-Xlint:-overrides'



    options.compilerArgs << '-Xlint:-path'



    options.compilerArgs << '-Xlint:-processing'



    options.compilerArgs << '-Xlint:-rawtypes'



    options.compilerArgs << '-Xlint:-serial'



    options.compilerArgs << '-Xlint:-static'



    options.compilerArgs << '-Xlint:-try'



    options.compilerArgs << '-Xlint:-unchecked'



    options.compilerArgs << '-Xlint:-varargs'



}

测试模块如下：

项目依赖如下：

在调试过程中，特意在事务执行的相应代码处增加了日志打印，通过分别测试postgresql和mysql发现，两者执行同样的方法，锁释放的时机均在事务完成提交之前，但唯一区别的是结果，无论怎么测试postgresql都不会出现“超卖”，而mysql则恰恰相反

这种事情显得很“诡异”，有同样遇到这种情况的大兄弟可以告诉我，这种是如何解释的

3.2.4 基于分布式锁与事务共用的解决方案

1、service方法上不加事务注解，在具体的reduce（repo）方法上加事务注解

这种执行结果是ok的，锁的释放在事务条件成功后释放

2、使用事务同步管理器，约束释放锁的时机必须在事务完成后才可以

并发测试结果是ok的，最终库存=0

3、service方法上不加@Transaction，在程序中，手动管理事务的提交和回滚

代码片段如下：

    @Autowired



    private JpaTransactionManager transactionManager;



 



   /**



	 * 第三种解决方案：service方法上不加@Transaction，在程序中，手动管理事务的提交和回滚



	 * @param commodityCode 商品编码



	 */



	@Override



	public Integer reduceLock3(String commodityCode) {



		int res = 0;



		RLock lock4Reduce = distributeLock.lock4Reduce(commodityCode);



		TransactionDefinition transactionDefinition = new DefaultTransactionDefinition();



		TransactionStatus txStatus = transactionManager.getTransaction(transactionDefinition);



		try{



			CommodityStockEntity stockEntity = stockRepo.findByCommodityCode(commodityCode);



			if(stockEntity == null){



				throw new EntityNotFoundException("指定的商品["+commodityCode+"]不存在！");



			}



			int inventory = stockEntity.getInventory();



			if(inventory == 0) {



				logger.warn("商品不够了，需要加库存！");



				return  0;



			}



			stockEntity.setInventory(inventory-1);



			stockRepo.save(stockEntity);



			transactionManager.commit(txStatus);



			return 1;



		}catch (Exception e){



			transactionManager.rollback(txStatus);



		}finally {



			if (lock4Reduce.isLocked() && txStatus.isCompleted()) {



				if (lock4Reduce.isHeldByCurrentThread()) {



					lock4Reduce.unlock();



					System.out.println("▲锁释放成功，当时时间："+ DateUtils.getCurrentTime());



				}



			}



		}



		return res;



	}

通用这种也是ok的

4、压根就不加锁，由上层进行锁控制

代码片段如下：

    // 使用redisson分布式锁(将service的锁粒度提到controller，“远离”@Transactional（aop），使得事务提交一定发生在锁释放之前)



    @GetMapping("/reduce/lock4/{commodityCode}")



    public Result commodityReduceLock4(@PathVariable("commodityCode") String commodityCode) throws Exception{



        RLock lock4Reduce = distributeLock.lock4Reduce(commodityCode);



        try{



            int reduce = commodityReduce.reduceLock4(commodityCode);



            if(reduce>0){



                return Result.ok("减库存成功！");



            }else{



                logger.info("商品{}已售罄",commodityCode);



                return Result.ok("商品已售罄！");



            }



        }finally {



            if (lock4Reduce.isLocked()) {



                if (lock4Reduce.isHeldByCurrentThread()) {



                    lock4Reduce.unlock();



                }



                System.out.println("controller,释放锁成功，当前时间："+ DateUtils.getCurrentTime());



            }



        }



    }



 



   /**



	 * 第四种解决方案：压根就不加锁，由上层进行锁控制



	 */



	@Override



	@Transactional(propagation = Propagation.NOT_SUPPORTED)



	public Integer reduceLock4(String commodityCode) {



		CommodityStockEntity stockEntity = stockRepo.findByCommodityCode(commodityCode);



		if(stockEntity == null){



			throw new EntityNotFoundException("指定的商品["+commodityCode+"]不存在！");



		}



		int inventory = stockEntity.getInventory();



		if(inventory == 0) {



			logger.warn("商品不够了，需要加库存！");



			return 0;



		}



		return stockRepo.reduce(commodityCode);



	}

3.3 基于zookeeper分布式锁的实现

orm选用tk-mybatis，数据库选用mysql，zk客户端连接选用curator框架，接口生成工具选用swagger，zk客户端工具选用ZooInspector

启动项目，浏览器输入：http://localhost:8088/swagger-ui.html

可视化工具

分布式锁代码片段

    @Autowired



    private CuratorFramework curatorFramework;



    



 



    @Transactional(rollbackFor = {Exception.class})



    @Override



    public Integer reduceLock(String commodityCode) throws Exception{



        // recipes不可重入的互斥锁



        InterProcessSemaphoreMutex lock = new InterProcessSemaphoreMutex (curatorFramework, "/lock");



        try{



            //获取锁资源



            boolean flag = lock.acquire(10, TimeUnit.SECONDS);



            if(flag){



                CommodityEntity entity = commodityMapper.findByCode(commodityCode);



                if(entity == null){



                    throw new MybatisEntityNotFoundException("所购的商品不存在！");



                }



                if(entity.getInventory() == 0){



                    logger.warn("商品不够了，需要加库存！");



                    return 0;



                }



                return commodityMapper.reduce(commodityCode);



            }



        }catch (Exception e){



            logger.error("错误信息：{}",e.getMessage());



        }finally {



            TransactionSynchronizationManager.registerSynchronization(new TransactionSynchronization() {



                @Override



                public void afterCompletion(int status) {



                    try {



                        lock.release();



                    } catch (Exception e) {



                        logger.info("错误信息：{}",e.getMessage());



                    }



                }



            });



        }



        return 0;



    }