我使用的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<lockTimeOut*1000){ -
transactionManager.commit(status); -
log.info("提交事务"); -
} else { -
log.error("异常：程序执行时间过长，锁超时!"); -
throw new BizException(ErrorCodeEnum.PROCESS_DATA_ERROR); -
}** -
}catch (Exception e){ -
//回滚事务 -
transactionManager.rollback(status); -
} finally{ -
//释放锁 -
lock.unlock(); -
} -
} else { -
log.error("获取锁失败！更新失败！"); -
throw new BizException(ErrorCodeEnum.PROCESS_DATA_ERROR); -
} -
}
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语句执行的成功/失败，是原子的，流程如下：
8、redis来充当公证人，利用的其 setnx指令的成功/失败，是原子的，流程如下：
9、为了防止线程宕机，造成锁死在那里挡道，需要给锁认定一个有效期限，
------此期限的自动失效解锁，与线程的主动解锁之间，会存在冲突，reids的解锁流程必须考虑这一点：
10、上图的解锁逻辑虽然是正确的，但因为整个动作不是原子的，因为不安全。需要改为lua脚本来执行
11、lua 脚本为什么是原子性的
----- redis是单线程执行指令的，因此内部不存在线程竞争
（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规范里，定义这样标准---- 事务管理器
事务管理器定义三个标准接口，即：
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
本堂课内容：
1、事务执行的中间态说明：
----- sql执行后，尚未提交 ，此时对应的数据状态：
-----正本数据（原来的数据） ----- 锁定状态-------允许其它线程读不允许改（此时易出现幻读）
-----副本数据（sql执行结果） ------ 隔离状态 ------其它线程是无法接触到的-------（可设置事务隔离级别，使其可读）未生效的数据 ---- 脏读
----- commit/rollback时出错 ------- 不能执行机率非常低
1845
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
