摘要:否则数据会出现不同步问题我使用的做分布式锁管理,用注解事务管理。但是出现另外一个问题,锁超时但是事务仍未提交。
最近开发一个小程序遇到一个需求需要实现分布式事务管理
业务需求用户在使用小程序的过程中可以查看景点,对景点地区或者城市标记是否想去,那么需要统计一个地点被标记的人数,以及记录某个用户对某个地点是否标记为想去,用两个表存储数据,一个地点表记录改地点被标记的次数,一个用户意向表记录某个用户对某个地点是否标记为想去。由于可能有多个用户同时标记一个地点,每个用户在前端点击想去按钮之后,后台接收到请求,从数据库查询某个城市的标记人数,再加1,然后更新到数据库。从数据库查询标记人数,再加1,然后更新到数据库这个过程数据库数据必须加锁,一次只能一个进程处理。否则数据会出现不同步问题
我使用的RedLock做分布式锁管理,用spring注解事务管理。
在实现过程中遇到如下两个映像深刻的问题:
1、分布式锁与spring注解事务共用产生的问题
2、锁在事务提交前超时问题
最初实现代码如下:
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); } }问题:高并发是锁没有生效
1、spring注解事务@Transactional和分布式锁不能一起使用
这是因为@Transactional是通过方法是否抛出异常来判断事务是否回滚还是提交,此时方法已经结束。但是我们必须在方法结束之前释放锁,
因此在释放锁之后,此时还没提交,由于锁已经释放,其他进程可以获得锁,并从数据库查询地点标记数,但是此时前一个进程没有提交数据。该进程查到的数据不是最新的数据。
这个问题我排查的时候花了很久,因为锁释放和提交事务之间只要几毫秒的时间,之前一直以为这么短的时间不可能是这里的问题,有怀疑过但是自己又放弃了
尽管这个过程只要很短的时间(我实际测试过程中这个过程只要几毫秒),但是高并发的情况还是会出问题。
由于不能使用注解事务,我改为手动事务管理,增加如下代码。
public markScenicSpot(){ //设置锁为destId 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); } }问题:锁超时事物异常
1、锁超时问题
在进行手动事务管理之后,解决的同步问题。但是出现另外一个问题,锁超时但是事务仍未提交。由于此时当前进程锁超时但是没有提交,此时其他进程可以获得锁并从数据库查询目的地标记数,但是不是更新之后的数据,取得的数据有误。
针对锁超时的情况,只需要当前进程提交之前增加一个判断,判断是否超时,如果超时抛出异常退出即可。
增加如下代码:
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总结 高并发情况下,分布式事务很容易出问题,要对各种情况分析是否可能出问题,并要对所有可能出问题的情况做充分的测试才能保证程序健壮。
文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。
转载请注明本文地址:https://www.ucloud.cn/yun/76878.html
摘要:它就是史上最简单的教程第三篇服务消费者后端掘金上一篇文章,讲述了通过去消费服务,这篇文章主要讲述通过去消费服务。概览和架构设计掘金技术征文后端掘金是基于的一整套实现微服务的框架。 Spring Boot 配置文件 – 在坑中实践 - 后端 - 掘金作者:泥瓦匠链接:Spring Boot 配置文件 – 在坑中实践版权归作者所有,转载请注明出处本文提纲一、自动配置二、自定义属性三、ran...
摘要:所以悲观锁是限制其他线程,而乐观锁是限制自己,虽然他的名字有锁,但是实际上不算上锁,只是在最后操作的时候再判断具体怎么操作。悲观锁和乐观锁比较悲观锁适合写多读少的场景。 最近在公司的业务上遇到了并发的问题,并且还是很常见的并发问题,算是低级的失误了。由于公司业务相对比较复杂且不适合公开,在此用一个很常见的业务来还原一下场景,同时介绍悲观锁和乐观锁是如何解决这类并发问题的。 公司业务就是...
阅读 916·2021-11-24 10:42
阅读 3461·2021-11-19 11:34
阅读 2593·2021-09-29 09:35
阅读 2492·2021-09-09 09:33
阅读 607·2021-07-26 23:38
阅读 2489·2019-08-30 10:48
阅读 1367·2019-08-28 18:07
阅读 405·2019-08-26 13:44