分布式锁Redisson原理解析

分布式锁的实现

目前来说分布式锁很多都是用Redis来实现的。但是redis存在很多的问题。应对一般的场景也没啥问题。建议还是能用zk就用zk。

Java下的分布式锁框架 redisson

Java生态是真的好。分布式锁框架也有人给你造。

        <dependency>
            <groupId>org.redisson</groupId>
            <artifactId>redisson-spring-boot-starter</artifactId>
            <version>3.20.0</version>
        </dependency>

看一下内部具体实现

org.redisson.RedissonLock#tryLockInnerAsync 加锁代码
使用的lua脚本实现的加锁逻辑

    <T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
        return evalWriteAsync(getRawName(), LongCodec.INSTANCE, command,
                "if (redis.call('exists', KEYS[1]) == 0) then " +
                        "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                        "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                        "return nil; " +
                        "end; " +
                        "if (redis.call('hexists', KEYS[1], ARGV[2]) == 1) then " +
                        "redis.call('hincrby', KEYS[1], ARGV[2], 1); " +
                        "redis.call('pexpire', KEYS[1], ARGV[1]); " +
                        "return nil; " +
                        "end; " +
                        "return redis.call('pttl', KEYS[1]);",
                Collections.singletonList(getRawName()), unit.toMillis(leaseTime), getLockName(threadId));
    }

我记得原来看到是用hset的 现在好像变了？？看到3.20.0最新也是hincrby估计是内部升级了

Redis Hincrby 命令用于为哈希表中的字段值加上指定增量值。

增量也可以为负数，相当于对指定字段进行减法操作。

如果哈希表的 key 不存在，一个新的哈希表被创建并执行 HINCRBY 命令。

如果指定的字段不存在，那么在执行命令前，字段的值被初始化为 0 。

对一个储存字符串值的字段执行 HINCRBY 命令将造成一个错误。

本操作的值被限制在 64 位(bit)有符号数字表示之内。

为什么使用lua脚本。因为redis就算是事务也没办法保证原子。所以需要使用lua脚本当作一条cmd发给redisRun

key[1] 这个参数代表的是你加锁的名字 就是外面调用传入的名字111

 RLock lock = redissonClient.getLock("111");

**ARGV[1]**代表的就是锁key的默认生存时间，默认30秒。代码在这里

        this.internalLockLeaseTime = commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout();
    private long lockWatchdogTimeout = 30 * 1000;

**ARGV[2]**代表的是加锁的客户端的ID，通过

getLockName(threadId) 获取的。
 long threadId = Thread.currentThread().getId();
    protected String getLockName(long threadId) {
        return id + ":" + threadId; //id进程ID
    }

这个lua脚本执行之后 会在redis内部生成一个这样的key-vale

111:{
 进程id:线程id
}
111:{123456:1}

然后给上过期时间30s 也就是所谓的看门狗机制
ok 到这里基本上加锁就完事了

锁互斥机制

那么在这个时候，如果客户端2来尝试加锁，执行了同样的一段lua脚本，会咋样呢？

很简单，第一个if判断会执行“exists myLock”，发现myLock这个锁key已经存在了。

接着第二个if判断，判断一下，myLock锁key的hash数据结构中，是否包含客户端2的ID，但是明显不是的，因为那里包含的是客户端1的ID。

所以，客户端2会获取到pttl myLock返回的一个数字，这个数字代表了myLock这个锁key的剩余生存时间。比如还剩15000毫秒的生存时间。

此时客户端2会进入一个while循环，不停的尝试加锁。

watch dog自动延期机制

客户端1加锁的锁key默认生存时间才30秒，如果超过了30秒，客户端1还想一直持有这把锁，怎么办呢？

简单！只要客户端1一旦加锁成功，就会启动一个watch dog看门狗，他是一个后台线程，会每隔10秒检查一下，如果客户端1还持有锁key，那么就会不断的延长锁key的生存时间（锁续命，延长过期时间）。

redis分布式锁的问题

因为在使用的时候都是用的集群或者多节点
他的master和slave之间采用复制的实现。如果在复制"锁"的时候 宕机。然后slave切换到master这时候线程2来加锁是能加锁成功的
解决方案就是redis作者的redLock 通过n/2 + 1节点加锁 有兴趣可以自己去看redis官网的redLock