分布式锁Redisson的源码总结--可重入锁篇

最近在看Redisson的源码，用了将近一周的时间终于看完了，现在总结一下比较重要的一些点，如果不够仔细，还请各位指出问题所在，如下是可重入锁的源码总结

1.    创建锁RLock lock = redisson.getLock("mylock");
创建的是RedissonLock
2.    lock.lock()或者lock.lock(1000,TimeUnit.SECONDS);
如果传入leasetime也就是上文的1000，则leasetime就是用传入的值，否则默认使用30000ms，也就是30秒

if (leaseTime != -1) {
    ttlRemainingFuture = tryLockInnerAsync(waitTime, leaseTime, unit, threadId, RedisCommands.EVAL_LONG);
} else {
    ttlRemainingFuture = tryLockInnerAsync(waitTime, internalLockLeaseTime,
    TimeUnit.MILLISECONDS, threadId, RedisCommands.EVAL_LONG);
}

3.    选择服务器，创建锁，根据创建的锁名称计算slot（一共有16384个），根据slot确定slot所在的服务器，
RFuture result = executorService.evalWriteAsync(key, codec, evalCommandType, script, keys, params);
NodeSource source = getNodeSource(key);
int slot = connectionManager.calcSlot(key);

4.    调用底层redis lua语句创建锁，判断锁是不是存在，判断是不是当前线程
·    "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]);",

样式如下：
mylock {
uuid:threadId:1
}

5.    创建锁返回值，如果是null则表示创建成功,否则返回锁过期时间ttl（实际是异步的RFuture）
6.    根据是否传入leasetime，如果传入则设置过期时间，如果未设置创建看门狗线程watchdog，是一个timertask，每隔internalLockLeasetime/3也就是10秒执行一次，如果没释放锁，则将锁的过期时间进行续期，续期到30秒
7.    如果创建锁失败（其他线程来创建锁），进入死循环返回锁过期时间，每隔过期时间后，去看一下所有没有释放
while (true) {
    ttl = tryAcquire(-1, leaseTime, unit, threadId);
       }
最后说一下Redisson的缺点：

因为它是在redis集群中挑选一个master实例来加锁，假设客户端刚刚在master写入一个锁，此时发生了master的宕机，但是master还没来得及将那个锁key异步同步到slave，slave就切换成了新的master。此时别的客户端在新的master上也尝试获取同一个锁，会成功获取锁

此时两个客户端，都会获取同一把分布式锁，可能有的时候就会导致一些数据的问题

redisson的分布式锁，隐患主要就是在这里