分布式锁
为什么使用分布式锁
随着业务发展的需要,原单体单机部署的系统被演化成分布式集群系统后,由于分布式系统多线程、多进程并且分布在不同机器上,这将使原单机部署情况下的并发控制锁策略失效,单纯的Java API并不能提供分布式锁的能力。为了解决这个问题就需要一种跨JVM的互斥机制来控制共享资源的访问,这就是分布式锁要解决的问题!
也就是说,相同的服务部署到不同的服务器上,如何保证相同的共享变量的一致性,即保证在同一时刻只能由一台服务器中的共享变量被一条线程修改。如线程1对jvm1中的变量A修改,如果没有做任何措施,jvm2,jvm3中的变量A是对这次修改不可见的。
分布式锁应该具备哪些条件
1、在分布式系统环境下,一个方法在同一时间只能被一个机器的一个线程执行;
2、高可用的获取锁与释放锁;
3、高性能的获取锁与释放锁;
4、具备可重入特性;
5、具备锁失效机制,防止死锁;
6、具备非阻塞锁特性,即没有获取到锁将直接返回获取锁失败。
如何实现分布式锁
分布式的CAP理论:任何一个分布式系统都无法同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance),最多只能同时满足两项。
基于数据库实现分布式锁;
基于缓存(Redis等)实现分布式锁;
setex key second value 等同于 set key value EX second; //在set的时候,同时指定key的过期时间s
psetex key millisecond value 等同于 set key value PX millsecond;//在set的时候,同时指定key的过期时间ms
setnx key value 等同于 set key value NX;//只有在key不存在的时,才对键进行设置操作此时返回1,如果key已经存在则返回0,即不能覆盖原来的值。
set key value XX;只有键存在,才能set
实现方式
SET lock_key random_value NX PX 5000
try{
lock = redisTemplate.opsForValue().setIfAbsent(lockKey, random_value ); //首先去获得锁,即执行setnx key value。如果返回1则获得锁成功,如果返回0,表示获得锁失败,这个random_value是服务器(即redis的客户端)随机产生,每个服务器产生的不同。
logger.info("cancelCouponCode是否获取到锁:"+lock);
if (lock) {//如果获得锁成功,则执行业务逻辑
// 执行业务逻辑
redisTemplate.expire(lockKey,1, TimeUnit.MINUTES); //设置key的过期时间,是为了避免死锁
return res; 返回执行的结果
}else {
logger.info("cancelCouponCode没有获取到锁,不执行任务!");
}
}finally{ //在finally中释放锁
if(lock){
redisTemplate.delete(lockKey);//释放锁,即将key删除
logger.info("cancelCouponCode任务结束,释放锁!");
}else{
logger.info("cancelCouponCode没有获取到锁,无需释放锁!");
}
缺点
在这种场景(主从结构)中存在明显的竞态:
客户端A从master获取到锁,
在master将锁同步到slave之前,master宕掉了。
slave节点被晋级为master节点,
客户端B取得了同一个资源被客户端A已经获取到的另外一个锁。安全失效!