本文主要是介绍商城项目【尚品汇】07分布式锁-1 setnx实现篇,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
文章目录
- 1.单体服务不加锁
- 1.1单体服务不加锁代码演示
- 1.2单体服务不加锁结果
- 1.3并发问题的原因
- 2.单体服务加synchronized
- 2.1单体服务加锁代码演示
- 2.2单体服务加锁结果
- 3.本地锁问题
- 4.分布式锁实现的解决方案
- 5.使用redis实现分布式锁(setnx)
- 5.1代码实现
- 5.2 实现逻辑
- 5.3 setnx实现分布式锁的问题1
- 5.4 针对误删锁的问题进行优化
- 5.5 setnx实现分布式锁的问题2
- 5.6针对删除锁的原子性问题进行优化
- 6.总结
1.单体服务不加锁
synchronized及lock锁,这些锁都是本地锁。接下来写一个案例,演示本地锁的问题
1.1单体服务不加锁代码演示
@RestController
@RequestMapping("admin/product/testLock")
public class TestController {@Autowiredprivate TestLockService testLockService;@GetMapping("noLock")public Result testLock(){testLockService.testLock();return Result.ok("没有锁");}
}
public interface TestLockService {void testLock();
}
@Service
public class TestLockServiceImpl implements TestLockService {@Autowiredprivate StringRedisTemplate stringRedisTemplate;@Overridepublic void testLock() {//1.获取redis中的num值String value = (String)stringRedisTemplate.opsForValue().get("num");//2.如果是空的话直接放回if (StringUtil.isBlank(value)){return;}//3.不是空,则将string转化为数值型int i = Integer.parseInt(value);i = i+1;//4.将num++ .将num转为string,保存至redisstringRedisTemplate.opsForValue().set("num",String.valueOf(i));}}
1.2单体服务不加锁结果
使用ab工具压力测试:5000次请求,并发100
初始值为0
1.3并发问题的原因
当a线程获取到值之后,在set值之前。b线程对值进行了修改。
2.单体服务加synchronized
2.1单体服务加锁代码演示
@RestController
@RequestMapping("admin/product/testLock")
public class TestController {@Autowiredprivate TestLockService testLockService;@GetMapping("synchronized")public Result testSynchronized(){testLockService.testSynchronized();return Result.ok("测试本地锁");}
}
public interface TestLockService {void testSynchronized();
}
@Overridepublic synchronized void testSynchronized() {//1.获取redis中的num值String value = (String)stringRedisTemplate.opsForValue().get("numLock");//2.如果是空的话直接放回if (StringUtil.isBlank(value)){return;}//3.不是空,则将string转化为数值型int i = Integer.parseInt(value);i = i+1;//4.将num++ .将num转为string,保存至redisstringRedisTemplate.opsForValue().set("numLock",String.valueOf(i));}
2.2单体服务加锁结果
使用ab工具压力测试:5000次请求,并发100
初始值为0
3.本地锁问题
接下来启动8206 8216 8226 三个运行实例。
运行多个service-product实例:
server.port=8216
server.port=8226
注意:bootstrap.properties 添加一个server.port = 8206; 将nacos的配置注释掉!
原因:Nacos中的远程配置,不支持本地覆盖,官方也没有这种打算,即使通过命令行指定的参数,也不能覆盖远程配置。
通过网关压力测试:
启动网关:
ab -n 5000 -c 100 http://192.168.142.1:81/admin/product/testLock/synchronized
查看redis中的值:初始值0
集群情况下又出问题了!!!
以上测试,可以发现:
本地锁只能锁住同一工程内的资源,在分布式系统里面都存在局限性。
此时需要分布式锁。。
4.分布式锁实现的解决方案
随着业务发展的需要,原单体单机部署的系统被演化成分布式集群系统后,由于分布式系统多线程、多进程并且分布在不同机器上,这将使原单机部署情况下的并发控制锁策略失效,单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问,这就是分布式锁要解决的问题!
分布式锁主流的实现方案:
- 基于数据库实现分布式锁
- 基于缓存(Redis等)set
- 基于Zookeeper实现分布式锁
每一种分布式锁解决方案都有各自的优缺点: - 性能:redis最高
- 可靠性:zookeeper最高
这里,我们就基于redis实现分布式锁。
5.使用redis实现分布式锁(setnx)
5.1代码实现
@GetMapping("testRedisLock")public Result testRedisLock(){testLockService.testRedisLock();return Result.ok();}
void testRedisLock();
@Overridepublic void testRedisLock() {/*** 使用Redis实现分布式锁* 主要是使用的setnx这个命令,如果键值不存在,则插入成功。如果存在则插入成功。*///1.尝试获取锁.设置key-value和过期时间(当某一个线程获取锁之后程序异常,那么锁就不会释放)Boolean lock = stringRedisTemplate.opsForValue().setIfAbsent("lock", "1", 3000, TimeUnit.SECONDS);//2.获取成功 ,进行加值的业务逻辑if (lock){String setnxLock = stringRedisTemplate.opsForValue().get("setnxLock");if (StringUtil.isBlank(setnxLock)){return;}int i = Integer.parseInt(setnxLock);i = i + 1;String s = String.valueOf(i);stringRedisTemplate.opsForValue().set("setnxLock",s);//4.释放锁stringRedisTemplate.delete("lock");}else{//3.获取失败 , 等待获取锁try {Thread.sleep(100);testRedisLock();} catch (Exception e) {e.printStackTrace();}}}
5.2 实现逻辑
- 1.使用setnx命令,若键存在则不可插入(返回false),若键不存在则插入成功(返回true)。
- 2.获取锁成功,处理业务
- 3.删除锁
- 4.获取锁失败,重试。
在setnx时要设置过期时间,如果不设置过期时间,在获取分布式锁成功时,程序出现异常不会释放锁。其他线程一直尝试获取锁会出现栈溢出异常
5.3 setnx实现分布式锁的问题1
问题:可能会释放其他服务器的锁。
场景:如果业务逻辑的执行时间是7s。执行流程如下
1.index1业务逻辑没执行完,3秒后锁被自动释放。
2.index2获取到锁,执行业务逻辑,3秒后锁被自动释放。
3.index3获取到锁,执行业务逻辑
4.index1业务逻辑执行完成,开始调用del释放锁,这时释放的是index3的锁, 导致index3的业务只执行1s就被别人释放。
最终等于没锁的情况。
解决:setnx获取锁时,设置一个指定的唯一值(例如:uuid);释放前获取这个值,判断是否自己的锁
当线程a业务逻辑执行的时间大于逻辑过期时间,业务a还没有执行完,由于逻辑过期就自动释放了锁,业务a执行完业务继续执行删除锁的操作,此时有可能就会删除其他线程的锁。人家刚刚获取到锁你给人家释放了,那和不加锁有什么区别吗????
5.4 针对误删锁的问题进行优化
在获取锁的时候赋值专属的ID,删除锁之前先判断是不是自己的ID
5.5 setnx实现分布式锁的问题2
场景:
1.index1执行删除时,查询到的lock值确实和uuid相等
2.index1执行删除前,lock刚好过期时间已到,被redis自动释放
在redis中没有了锁。
3.index2获取了lock,index2线程获取到了cpu的资源,开始执行方法
4.index1执行删除,此时会把index2的lock删除
index1 因为已经在方法中了,所以不需要重新上锁。index1有执行的权限。index1已经比较完成了,这个时候,开始执行
删除的index2的锁!
他的if条件判断和删除操作不是一起执行的,那么a线程刚刚判断完进入了删除操作的逻辑,在执行删除前逻辑过期自动删除了,而且其他线程获取了锁,然后a线程删除了其他线程的锁。也就是这样优化的话也会出现误删的情况,只是概率比优化之前低了一点。
5.6针对删除锁的原子性问题进行优化
加锁
// 1. 从redis中获取锁,set k1 v1 px 20000 nx
String uuid = UUID.randomUUID().toString();
Boolean lock = this.redisTemplate.opsForValue().setIfAbsent("lock", uuid, 2, TimeUnit.SECONDS);
使用Lua脚步释放锁
// 2. 释放锁 del
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
// 设置lua脚本返回的数据类型
DefaultRedisScript<Long> redisScript = new DefaultRedisScript<>();
// 设置lua脚本返回类型为Long
redisScript.setResultType(Long.class);
redisScript.setScriptText(script);
redisTemplate.execute(redisScript, Arrays.asList("lock"),uuid);
6.总结
为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件:
- 互斥性。在任意时刻,只有一个客户端能持有锁。
- 不会发生死锁。即使有一个客户端在持有锁的期间崩溃而没有主动解锁,也能保证后续其他客户端能加锁。
- 解铃还须系铃人。加锁和解锁必须是同一个客户端,客户端自己不能把别人加的锁给解了。
- 加锁和解锁必须具有原子性
redis集群状态下的问题:
- 客户端A从master获取到锁
- 在master将锁同步到slave之前,master宕掉了。
- slave节点被晋级为master节点
- 客户端B取得了同一个资源被客户端A已经获取到的另外一个锁。
安全失效!
解决方案:了解即可!
这篇关于商城项目【尚品汇】07分布式锁-1 setnx实现篇的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!