redis分布式锁

最新推荐文章于 2024-03-02 22:22:24 发布

isTrueLoveColour

最新推荐文章于 2024-03-02 22:22:24 发布

阅读量254

点赞数

分类专栏： redis 文章标签： redis 分布式数据库

本文链接：https://blog.csdn.net/persistence_PSH/article/details/134230947

版权

redis 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

分布式锁

为什么使用分布式锁：

加锁的目的是为了防止代码的重复执行，在单机情况下，可以使用 jvm的锁：lock和synchronized进行加锁
但是在分布式系统下，每个jvm是相互隔离的，JVM锁没有互斥性，所以需要引入第三方进行加锁

常用的分布式锁实现方案：

mysql
- 利用mysql 表的主键或者唯一索引不能重复，插入数据成功代表加锁成功，插入失败代表获取锁失败，执行完成删除表中数据就是释放锁
- 但因为是磁盘IO，代价比较大，不适合大型项目
Redis
zookeeper

Redis分布式锁

redis分布式锁的要求

锁需要有独占性，任何时刻有且只能有一个线程持有
并且要保证高可用，redis集群情况下，不能因为某个节点挂了，就出现获取锁和释放锁失败的情况
要有超时机制或者撤销操作，防止死锁
防止锁被其他线程误删
锁需要保证重入性

Redis分布式锁的实现

简单来说Redis实现锁机制其实就是在Redis中设置一个key-value，当key存在时，即上锁，删除key即解锁。
使用 setnx + del ，先加锁用完后释放锁，这种情况如果执行过程中出现异常，可能导致del指令没有被调用，锁会永远得不到释放，就会产生死锁
- 所以需要给锁增加过期时间，保证锁可以自动释放，但是setnx 和expire 是两条指令，它们不是原子的，如果在设置过期时间时，出现异常，同样会导致锁得不到释放
- 所以redis 在2.8 版本增加了，set的扩展命令（set ex px nx），使得setnx 和expire 可以一起执行，如果redis版本较低，可以使用lua脚本保证两个指令的原子性
如果没有获取到锁，锁的重试需要暂停一段时间，以减少不必要的空转，但是等待时间需要根据时间业务进行评估，等待时间过长容易造成业务阻塞，时间过短，可能会造成大量的空转，浪费系统资源
此外还有可能会遇到超时问题，也就是锁过期释放了，但业务还没执行完，此时就会有其他线程获取到新的锁
- 这时需要增加一个看门狗，定期检查业务线程有没有执行完，如果没有就要续锁，防止业务没有执行完，锁被释放掉了
- 但是如果在需要续锁的时候，jvm进行垃圾回收了，触发STW机制，导致续锁不及时，key仍然有过期风险，可以通过 zookeeper 解决
也有可能原本的程序执行完了，去删除锁时，自身的锁过期了，从而误删除了其他线程加的锁
- 所以设置一个唯一的value值，在删除锁时，需要先判断value值是不是自己的，如果不是就不能删除，防止删除了其他线程的锁
- 但是匹配value和删除key又不是一个指令，这里就需要使用lua脚本了
此外还要保证锁的重入性，但是并不推荐redis使用可重入锁，它加重了客户端的复杂性，调整业务结构完全可以避免可重入锁

锁的重入性

一个线程获取到锁后，再进入该线程的内部方法如果还需要获得相同的锁，就会自动获得锁，不会因为之前获得过还没有释放而阻塞，可重入锁能再一定程度上避免死锁
redis分布式锁想要保证可重入性，就需要使用hash结构，使用String无法保证可重入性，加锁解锁操作都需要使用lua脚本保证原子性

看门狗

锁过期释放了，但业务还没执行完，就需要锁的续期，防止任务没有执行完，锁被释放掉了，同样需要lua脚本

如果redis客户端加锁请求失败：

可以直接抛出异常，这种适合由用户发起的操作，用户看到错误后，可以点击重试
或者让线程休眠一会儿，然后在重试，但是这种会阻塞消息处理线程，如果队列里的消息很多，sleep并不合适
或者将请求转移到延时队列，过一会儿在试

lua

轻量级的脚本语言，C语言编写，嵌入应用程序中，为程序提供灵活的扩展和定制功能

redis调用lua脚本，通过eval命令保证redis命令的原子性，用return返回脚本执行后的结果，例如：

-- eval后面跟的是脚本， 一个redis.call()代表一个redis命令
eval " redis.call('set','test','1234')  redis.call('expire','test','60')  return redis.call('get','test') " 0
-- 上面的脚本是写死的，用动态参数代替后为:
eval " redis.call('set',KEYS[1],ARGV[1])  redis.call('expire',KEYS[1],'60')  return redis.call('get',KEYS[1]) " 1  test  1234

lua脚本参数说明

eval "return redis.call('mset','k1','v1','k2','v2') " 0
-- 上面的脚本是写死的，用动态参数代替后为: 
-- KEYS代表key， ARGV代表value，，下标都是从1开始
-- 2代表参数的个数，后面的key和value要一一对应
eval "return redis.call('mset',KEYS[1],ARGV[1],KEYS[2],ARGV[2]) " 2  k1  k2 v1 v2

-- if语法说明 ，有if一定有end，除了最后一个else都有then
if (布尔条件) then
    业务代码
elseif (布尔条件) then
	业务代码
else 
    业务代码
end

redis官网的lua脚本如下：

-- 获取key的value值，和输入的value进行比较，相同就删除key并返回删除结果，否则返回0
if redis.call("get",KEYS[1]) == ARGV[1] then
    return redis.call("del",KEYS[1])
else
    return 0
end

改写后为：注意单双引号

eval " if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1]) else  return 0 end" 1 testLock 1234

hash类型的分布式锁 lua脚本

加锁
- 先判断key是否存在，不存在就加锁，存在就判断锁是否是自己的
- hash做分布式锁，<key,<vaule，加锁的次数> >
- 返回1说明加锁成功，返回0加锁失败

-- 第一个条件是锁存在，第二条件是锁的value存在
if redis.call('exists',KEYS[1])==0 or redis.call('hexists',KEYS[1],ARGV[1])==1 then
   -- hincrby包含了hset, key2是uuid ,1是增长的步长值
	redis.call('hincrby',KEYS[1],ARGV[1],1)
   --设置过期时间
    redis.call('expire',KEYS[1],ARGV[2])
    return 1  
else
    return 0   
end

-- 缩进后：
eval "if redis.call('exists',KEYS[1])==0 or redis.call('hexists',KEYS[1],ARGV[1])==1 then redis.call('hincrby',KEYS[1],ARGV[1],1) redis.call('expire',KEYS[1],ARGV[2]) return 1  else return 0   end" 1 testhashLock 1111 60

解锁
- 先判断有没有锁，没有锁返回null
- 有锁，就减少锁的加锁次数，返回0
- 如果加锁的次数为0，就删除锁，删除锁后返回1

-- 锁不存在
if  redis.call('hexists',KEYS[1],ARGV[1])==0 then
    return nil
--减少锁的加锁次数，如果加锁的次数为0，就删除锁  
elseif redis.call('hincrby',KEYS[1],ARGV[1],-1)==0 then    
    return  redis.call('del',KEYS[1])
else    
    return 0   
end


eval "if  redis.call('hexists',KEYS[1],ARGV[1])==0 then return nil  elseif redis.call('hincrby',KEYS[1],ARGV[1],-1)==0 then    return  redis.call('del',KEYS[1]) else  return 0   end" 1 testhashLock 1111

自动续期 lua 脚本

-- 过了一段时间后，发现锁还在，就要续期
if  redis.call('hexists',KEYS[1],ARGV[1])==1 then
    return  redis.call('expire',KEYS[1],ARGV[2])
else    
    return 0   
end

--测试，先加一个key，设置过期时间再续期

hset  testhashLock 1111  1
expire  testhashLock  60
ttl testhashLock

eval "if  redis.call('hexists',KEYS[1],ARGV[1])==1 then  return  redis.call('expire',KEYS[1],ARGV[2]) else  return 0   end" 1 testhashLock 1111 60

Redlock

redis的红锁方案（Redlock）：

redis分布式锁，在主从情况下是不可靠的，因为redis的复制是异步的，所以即使是在集群模式下运行，如果在加锁时 redis 主节点故障，从节点还未来得及同步锁就升级为主节点，此时其他线程就可以再次加锁，这样就会导致多个线程都持有锁，可以通过红锁解决
红锁本质上就是使用多个Redis做锁，官网的示例采用的是5个节点，这些节点完全互相独立，没有主从关系，和很多分布式算法一样，红锁也采用大多数机制
在奇数台redis上加锁，一次锁的获取，会对每个请求都获取一遍，如果获取锁成功的数量超过一半，则获取锁成功，反之失败；
红锁的问题：
- 如果有节点宕机了，需要等待红锁的key过期或者释放掉才能重启，否则也有可能加锁失败代码重复执行
- 会增加系统复杂度，而且会降低效率

redisson的git地址:

https://github.com/redisson/redisson

红锁的设计理念

多个节点完全互相独立，没有主从关系，也不使用复制和其他隐式协调系统
获取客户端锁时，首先获取当前时间，
依此获取5个实例，使用相同的key和随机值获取锁，客户端设置一个超时时间，超时时间应该小于锁的失效时间，可以防止客户端与一个宕机的redis节点长时间处于阻塞状态，如果一个redis服务器不可用，就要去请求其他redis获取锁
客户端通过当前时间减去最开始记录的时间，来计算获取锁使用的时间，只有大多数的redis节点（N/2 +1）都获取到锁，并且获取锁的时间小于锁的失效时间，才算锁获取成功
所以锁的有效时间是，初始有效时间减去获取锁使用的时间
如果没能获得锁，需要在所有的redis实例上进行解锁，因为可能部分加锁成功，部分加锁失败

红锁节点个数：N = 2 X +1

N是最终部署的机器数
X是容错机器数，也就是宕机多少台红锁依然可用
因为要保证过半的节点可用，所以奇数台是经历的方法

redisson

redis官方给的红锁实现，封装了分布式锁的实现，底层使用的是hash结构保证了锁的可重入性，还使用了lua脚本保证原子性，锁的超时时间默认是30s
redisson支持MultLock机制，可以将多个锁合并为一个大锁，然后禁止统一管理，加锁和解锁
加锁流程：
- 通过exists判断，锁如果不存在，就设置值和过期时间，加锁成功
- 如果锁已存在，通过hexists判断，锁的是当前线程，就是可重入锁，加锁成功
- 如果锁已存在，通过hexists判断，锁的不是当前线程，加锁失败，返回锁的过期时间
解锁流程：
- 通过hexists判断，释放锁的线程和持有锁的线程是不是同一个，不是就返回null,
- 是就减少锁的加锁次数，并刷新锁的过期时间
- 如果加锁的次数为0，就删除锁，并发布解锁的消息后
还会额外启动一个线程，也就是看门狗，它的作用是在redisson实例关闭前，来定期检查线程是否还持有锁，如果持有锁，就刷新锁的过期时间（30s），看门狗刷新的频率是锁过期时间的1/3，也就是10s刷新一次
此外redisson还提供了参数，指定加锁时间，超过这个时间后锁会自动解开，即使不释放锁也会解开，防止了死锁
多机情况下，ReadLock已被弃用，推荐使用 MultLock，MultLock符合juc的lock规范

示例：

    @Resource
    private Redisson redisson;

	public BaseResultModel reduce() {
        RLock lock = redisson.getLock(COMMODITY_KEY_LOCK_REDISSON);
        //加redis分布式锁
        lock.lock();
        
        try {

        } catch (Exception e) {
            e.printStackTrace();
        } finally {
            //判断锁是否是当前线程的
            if (lock.isLocked()&&lock.isHeldByCurrentThread()){
                //释放redis分布式锁
                lock.unlock();
            }
        }
        return BaseResultModel.success("执行成功“);
    }

isTrueLoveColour

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
1
评论
redis分布式锁

- 加锁的目的是为了防止代码的重复执行，在单机情况下，可以使用 jvm的锁：lock和synchronized进行加锁- 但是在分布式系统下，每个jvm是相互隔离的，JVM锁没有互斥性，所以需要引入第三方进行加锁
复制链接

扫一扫