锁和事务冲突

我使用的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);
   }
 }

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

spring注解事务@Transactional和分布式锁一起使用的问题

这是因为@Transactional是通过方法是否抛出异常来判断事务是否回滚还是提交,此时方法已经结束。但是我们必须在方法结束之后释放锁,因此在释放锁之后,此时事务还没提交,由于锁已经释放,其他进程可以获得锁,并从数据库查询地点标记数,但是此时前一个进程没有提交数据。该进程查到的数据不是最新的数据。尽管这个过程只要很短的时间(我实际测试过程中这个过程只要几毫秒),但是高并发的情况还是会出问题。

解决1:可以手动控制事务的提交,可以控制在事务提交后释放锁

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);
   }
 }

问题:锁超时事物异常 

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

解决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

2、分布式锁在事务提交前进行释放的问题:

事务是在service方法中,将释放锁的代码上提到controller层进行处理,这样就是事务提交后再释放锁。

 

可以通过拆分一个Service的事务、锁的两部分工作,拆成2个Service,

Controller调用第一个Service(加锁、释放锁),第一个Service再调用第二个Service(事务控制部分)

示例,修改前

HelloController
   --HelloService
               事务开始
                 加锁
                     // 业务代码
                     解锁
                 事务结束

示例,修改后

HelloController
   --LockService
            加锁
              --HelloService
                   事务开始
                         // 业务代码
                    事务结束
            解锁

 这个还是比较靠谱

 

根据事例总解如下:

 

单机里面,完美解决了锁与事务

一、使用锁的原因分析:

1、使用锁的目的

------------多个外部线程同时来竞争使用同一资源时,会彼此影响,导致混乱

------------锁的目的,将资源的使用做排它性处理,使同一时间,仅一个线程能访问资源

2、并不是所有的资源,都无法同时服务多个线程 ------ 比如,无状态的资源

3、无成员变量/成员变量不存在变化的类---- 就是无状态类 ----- 这种类是线程安全的

4、有状态的对象,也不一定是不安全的

---------- 如果状态变化是原子的(即没有中间变迁过程,变化不需要时间,没有中间态) ---- 那么它一样是线程安全的

5、重要的概念,动作的原子性

6、总结:锁的本质

锁要解决的问题是 ------- 资源数据会不一致

锁要达成的目标是 ------- 让资源使用起来,像原子性一样

锁达成目标的手段 ------- 让使用者访问资源时,只能排队,一个一个地去访问资源

二、在单机应用里,JVM可以通过以下工具,可协调资源像原子性一样操作

1、sychronized ------ java语言天生支持

2、lock ---- jdk有接口标准

 

三、分布式环境下,如何协调资源达到原子性的操作?

1、sychronized / lock 这些java天然的实现,无法跨JVM发挥作用

2、只得去寻求分布式环境里,大家都公认的服务来做见证人,以协调资源

3、常见的公证人 ------》 mysql/zk/file/redis

4、目标 ----- 通过公证人发出信号,来协调分布式的访问者,排队访问资源

5、条件 ----- 任何一个能够提供【是/否】信号量的事物,都可以来做公证人

6、陷阱 ----- 发出锁信号量的动作,本身必须是原子性的

7、mysql来充当公证人,利用的是一条sql语句执行的成功/失败,是原子的,流程如下:

锁和事务冲突_第1张图片

8、redis来充当公证人,利用的其 setnx指令的成功/失败,是原子的,流程如下:

锁和事务冲突_第2张图片

9、为了防止线程宕机,造成锁死在那里挡道,需要给锁认定一个有效期限,

------此期限的自动失效解锁,与线程的主动解锁之间,会存在冲突,reids的解锁流程必须考虑这一点:

锁和事务冲突_第3张图片

10、上图的解锁逻辑虽然是正确的,但因为整个动作不是原子的,因为不安全。需要改为lua脚本来执行

锁和事务冲突_第4张图片

11、lua 脚本为什么是原子性的

----- redis是单线程执行指令的,因此内部不存在线程竞争

锁和事务冲突_第5张图片

(1)服务器A依次发送了ab指令到redis

(2)服务器B依次发送了cd指令到redis

(3)两台机器同向redis发送的四条指令,最终在指令队列里顺序是:acbd

(4)可以看到,服务器A发送的ab两条指令,中间穿插了c指令,破坏了其完整性,因此,ab两条指令不是原子的

(5)lua脚本,被放进队列时,ab指令是放在一起的,因为ab会顺序一起被执行,成为了原子性动作

四、事务的概念

1、锁的问题   ----- 多对一的问题 ------ 是多个线程同时访问同一个资源,造成资源状态不一致

2、事务的问题 ----- 一对多的问题 ----- 是一个线程进数据库,操作多条sql,其中,某条sql的失败,致使整个业务失去意义;

3、数据库中事务的实现方式:

------------------ service执行一个操作,要执行N条sql( 一条sql 是一个原子性操作)

--------- 数据库内部,如何实现事务?

--------- 所有的sql执行完毕之前,结果都以副本形式存在,如下图

------- commit操作 ------ 业务线程向数据库发指令 ----- 把副本转正

------ roback操作 ------- 把副本丢掉

4、jdbc规范里,定义这样标准---- 事务管理器

锁和事务冲突_第6张图片

事务管理器定义三个标准接口,即:

1、启动事务(启动副本),

2、副本转正

3、副本丢弃

 

五、分布式事务

1、分布式事务,是指多台数据库的执行sql,也想要达到一致性的标准,即:多台一起commit或rollback

2、参照单机事务的模型,分布式事务的思路延袭,也想通过三个标准接口的模式来完成(启副本/commit/rollback)

3、按这个思路, X/Open组织提出了分布式事务的规范 ----- XA

4、XA的核心,便是全局事务,通过XA二阶段提交协议,与各分布式数据交互,分准备与提交两个阶段,如下图:

课程回顾:

1、锁的本质,资源的操作不是原子 -------- 锁目标,让一系列操作,一次性做完。排队

2、分布式环境下,一切能够发出两个信号量事物都能够做锁 ----- 做锁要求:加锁/解锁两个动作,一定是原子的

3、mysql来做锁 ------- 一条sql的执行,是原子的

4、redis有做锁 -------- setnx操作,是原子的

5、redis要做安全的锁,----- 加锁进程死掉,--------  有效期使用解锁过程复杂化--锁判断----lua脚本来保证原子性

6、锁 ---- 多个线程操作一个资源 ; 事务 ----- 一个线程,操作多个资源问题。

7、事务 ----- ACID ----- 启事务/commit/rollback

8、X/open组织提出分布式事务规范 ---- XA

锁和事务冲突_第7张图片

 

本堂课内容:

1、事务执行的中间态说明:

----- sql执行后,尚未提交 ,此时对应的数据状态:

                  -----正本数据(原来的数据)   ----- 锁定状态-------允许其它线程读不允许改(此时易出现幻读)

                  -----副本数据(sql执行结果)  ------ 隔离状态 ------其它线程是无法接触到的-------(可设置事务隔离级别,使其可读)未生效的数据 ---- 脏读

                  ----- commit/rollback时出错     ------- 不能执行机率非常低

你可能感兴趣的:(java)