Redisson分布式锁实现原理

Redisson主要解决一下问题

1. 重入问题：重入问题是指 获得锁的线程可以再次进入到相同的锁的代码块中，可重入锁的意义在于防止死锁，比如HashTable这样的代码中，他的方法都是使用synchronized修饰的，假如他在一个方法内，调用另一个方法，那么此时如果是不可重入的，不就死锁了吗？所以可重入锁他的主要意义是防止死锁，我们的synchronized和Lock锁都是可重入的。
2. 不可重试：是指目前的分布式只能尝试一次，我们认为合理的情况是：当线程在获得锁失败后，他应该能再次尝试获得锁。
3. 超时释放：我们在加锁时增加了过期时间，这样的我们可以防止死锁，但是如果卡顿的时间超长，虽然我们采用了lua表达式防止删锁的时候，误删别人的锁，但是毕竟没有锁住，有安全隐患
4. 主从一致性：如果Redis提供了主从集群，当我们向集群写数据时，主机需要异步的将数据同步给从机，而万一在同步过去之前，主机宕机了，就会出现死锁问题。

一、分析可重入

1.原理

在Lock锁中，他是借助于底层的一个voaltile的一个state变量来记录重入的状态的，比如当前没有人持有这把锁，那么state=0，假如有人持有这把锁，那么state=1，如果持有这把锁的人再次持有这把锁，那么state就会+1 ，如果是对于synchronized而言，他在c语言代码中会有一个count，原理和state类似，也是重入一次就加一，释放一次就-1 ，直到减少成0 时，表示当前这把锁没有被人持有。

在redission中，也支持可重入锁

在分布式锁中，他采用hash结构用来存储锁，其中大key表示表示这把锁是否存在，用小key表示当前这把锁被哪个线程持有，所以接下来我们一起分析一下当前的这个lua表达式

2、获取锁源码

我们点进去Redisson获取锁的源码 

可以发现如下代码 

 也就是下面的代码

-- 判断是否存在
if ((redis.call('exists', KEYS[1]) == 0)
        -- 存在，判断是否是自己的锁 
        or (redis.call('hexists', KEYS[1], ARGV[2]) == 1)) then
    -- 不存在，获取锁或者是自己的锁，次数加1
    redis.call('hincrby', KEYS[1], ARGV[2], 1);
    -- 设置过期时间
    redis.call('pexpire', KEYS[1], ARGV[1]);
    -- 返回nil
    return nil;
end ;
-- 返回剩余过期时间
return redis.call('pttl', KEYS[1]);

1.这个地方一共有3个参数3

KEYS[1] ： 锁名称

ARGV[1]： 锁失效时间

ARGV[2]： id + ":" + threadId; 锁的小key

exists: 判断数据是否存在 name：是lock是否存在,如果==0，就表示当前这把锁不存在

redis.call('hincrby', KEYS[1], ARGV[2], 1);

直接获取锁，并且计数器置1

如果当前这把锁存在，则第一个条件不满足，再判断

redis.call('hexists', KEYS[1], ARGV[2]) == 1

此时需要通过大key+小key判断当前这把锁是否是属于自己的，如果是自己的，则进行

redis.call('hincrby', KEYS[1], ARGV[2], 1)

将当前这个锁的value进行+1 ，redis.call('pexpire', KEYS[1], ARGV[1]); 然后再对其设置过期时间，如果以上两个条件都不满足，则表示当前这把锁抢锁失败，最后返回pttl，即为当前这把锁的失效时间

3、释放锁源码 

-- 判断锁是否存在
if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then
    return nil;
end;

-- 存在，计数器-1
local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1);

-- 如果计数器大于0，则设置过期时间
if (counter > 0) then
    redis.call('pexpire', KEYS[1], ARGV[2]);
    return 0;
else
    -- 否，则释放锁
    redis.call('del', KEYS[1]);
    -- 同时发布一个消息到指定channel，通知锁已经释放
    redis.call('publish', KEYS[2], ARGV[1]);
    return 1;
end;

return nil;

首先判断锁是否存在，存在则计数器-1，如果计数器大于0，则刷新过期时间，否则释放锁，同时发布消息，通知已释放锁 

4、流程图 

整个流程也就是这个流程图

 二、分析解决不可重试

重试获取锁机制

trylock源码

这里默认ttl为-1

注意tryAcquire方法,返回值为ttl，ttl为null即为获得锁成功

这里由于默认存活时间为-1，所以下面参数默认存活时间为

this.commandExecutor.getConnectionManager().getCfg().getLockWatchdogTimeout()
（watchdog看门狗）也就是30s，如果我们自己传了过期时间，就不会调用看门狗了。

查看trylockInnerAsync方法

这里会返回剩余过期时间

和上面的代码一样接下来回到trylock源码

@Override
    public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
        long time = unit.toMillis(waitTime);
        long current = System.currentTimeMillis();
        long threadId = Thread.currentThread().getId();
        Long ttl = tryAcquire(waitTime, leaseTime, unit, threadId);
        // lock acquired
        if (ttl == null) {
            return true;
        }
        
        time -= System.currentTimeMillis() - current;
        if (time <= 0) {
            acquireFailed(waitTime, unit, threadId);
            return false;
        }
        
        current = System.currentTimeMillis();
        RFuture<RedissonLockEntry> subscribeFuture = subscribe(threadId);
        if (!subscribeFuture.await(time, TimeUnit.MILLISECONDS)) {
            if (!subscribeFuture.cancel(false)) {
                subscribeFuture.onComplete((res, e) -> {
                    if (e == null) {
                        unsubscribe(subscribeFuture, threadId);
                    }
                });
            }
            acquireFailed(waitTime, unit, threadId);
            return false;
        }

        try {
            time -= System.currentTimeMillis() - current;
            if (time <= 0) {
                acquireFailed(waitTime, unit, threadId);
                return false;
            }
        
            while (true) {
                long currentTime = System.currentTimeMillis();
                ttl = tryAcquire(waitTime, leaseTime, unit, threadId);
                // lock acquired
                if (ttl == null) {
                    return true;
                }

                time -= System.currentTimeMillis() - currentTime;
                if (time <= 0) {
                    acquireFailed(waitTime, unit, threadId);
                    return false;
                }

                // waiting for message
                currentTime = System.currentTimeMillis();
                if (ttl >= 0 && ttl < time) {
                    subscribeFuture.getNow().getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
                } else {
                    subscribeFuture.getNow().getLatch().tryAcquire(time, TimeUnit.MILLISECONDS);
                }

                time -= System.currentTimeMillis() - currentTime;
                if (time <= 0) {
                    acquireFailed(waitTime, unit, threadId);
                    return false;
                }
            }
        } finally {
            unsubscribe(subscribeFuture, threadId);
        }
//        return get(tryLockAsync(waitTime, leaseTime, unit));
    }

unlock源码

这里会发布释放锁的消息

如果ttl为null那么返回true代表获取成功

否则用最大等待时间time减去上面的系统时间算出这段代码的耗时，如果为负数说明超过最大等待时长，返回false,如果time大于0,不直接判断，因为此时别的线程获取锁正在执行，假设立马执行只是会浪费cpu资源，所以这里用了subscribe（threadId）方法来订阅锁释放的信息（上面的unlock代码释放锁会发布信息），然后采用计数器进行等待，等待时长为time，假设没等到，返回false，那么使用unsubscribe()方法结束订阅，返回false。

如果等到别的线程释放锁，就再次判断上面代码是否超时，超时返回false，否则再次调用tryAcquire方法

如果ttl小于等待时间time，那么就尝试ttl时间，否则就尝试获取锁在time时间内，

直到time结束，这就时重试获取锁机制

三、Redisson锁超时解决原理

如果业务堵塞导致过期，并未主动释放锁，从而导致其他线程获取锁，这时容易产生安全问题,一起看看redisson如何解决这个问题

在tryAcquireAsync方法中，会执行onComplete方法，，会调用scheduleExpirationRenewal(threadId)方法时间表刷新方法。

这里创建一个ExpirationEntry类

Redisson 中的 ExpirationEntry 是 Redisson 框架中用于管理 Redis 数据过期的一个内部数据结构，通常不是公共 API 的一部分。ExpirationEntry主要用于实现 Redisson 提供的分布式对象（例如分布式 Map、分布式集合等）的过期功能。这个类不是 Redis 自身的概念，而是 Redisson 框架为了实现某些功能而引入的内部结构。

具体来说，ExpirationEntry用于跟踪 Redisson 中的某个分布式对象的过期时间，以便在数据过期时能够自动清理或触发相应的操作。这对于缓存、锁或其他需要管理过期数据的分布式场景非常有用。

这个类的具体实现和使用方式通常是 Redisson 框架内部的细节，一般不需要直接操作它。Redisson 提供了高级的分布式数据结构和工具，开发人员可以直接使用这些工具来构建分布式应用程序，而不必关心底层的细节。

然后执行了puIfAbsent方法,这里的EntryName是当前连接id+创建RLock时传入的锁的名称

第一次执行会进入renewExpiration方法

private void renewExpiration() {
        ExpirationEntry ee = EXPIRATION_RENEWAL_MAP.get(getEntryName());
        if (ee == null) {
            return;
        }
        
        Timeout task = commandExecutor.getConnectionManager().newTimeout(new TimerTask() {
            @Override
            public void run(Timeout timeout) throws Exception {
                ExpirationEntry ent = EXPIRATION_RENEWAL_MAP.get(getEntryName());
                if (ent == null) {
                    return;
                }
                Long threadId = ent.getFirstThreadId();
                if (threadId == null) {
                    return;
                }
                
                RFuture<Boolean> future = renewExpirationAsync(threadId);
                future.onComplete((res, e) -> {
                    if (e != null) {
                        log.error("Can't update lock " + getName() + " expiration", e);
                        return;
                    }
                    
                    if (res) {
                        // reschedule itself
                        renewExpiration();
                    }
                });
            }
        }, internalLockLeaseTime / 3, TimeUnit.MILLISECONDS);
        
        ee.setTimeout(task);
    }

这是一个延迟执行的方法，延迟时间为

this.internalLockLeaseTime / 3L，如果开始未传入ttl时间那么默认internalLockLeaseTime为看门狗时间30s，如果传入的有ttl，以传入的为准。

这个任务执行的是

RFuture<Boolean> future = renewExpirationAsync(threadId);

刷新过期时间，然后再调用自己

 

等于说是每过ttl时间的三分之一就执行这个任务一次相当于不会出现因为业务代码延迟导致锁的ttl时间过期，那么怎么释放呢

看unlock

进入unlockAsync方法

如果有异常就是e!=null。进入cancelExpirationRenewal方法

这里就解决了定时刷新的问题

也就是说如果不设置存活时间，那么会利用看门狗执行任务刷新等待

释放锁逻辑图