Redis分布式锁之：RedLock

redLock也是Redis提供的一个分布式锁，和redissonLock有些区别

是什么

RedLock可以指定等待时间，也就是说，假如我指定了等待时间waitTime是2S，比如：
1.A线程来加锁，正常去执行业务逻辑
2.B线程也来加锁，此时会加锁失败，那B线程最多等待2S，如果超过了2S还没有获取到分布式锁，那B线程加锁就返回false，表示加锁失败

redLock的思想是：

1. redLock的使用，需要有奇数台独立部署的Redis节点
2. 在加锁的时候，会分别去N台节点上加锁，如果半数以上的节点加锁成功，就认为当前线程加锁成功

还有一个点：不管是redLock，还是redissonLock，两者底层都是通过相同的lua脚本来加锁、释放锁的，所以，两者只是外部形态的不同，底层是一样的

redLock是继承了redissonMultiLock，大部分的逻辑，都是在redissonMultiLock中去实现的，所以源码部分，大部分都是RedissonMultiLock

加锁源码

org.redisson.RedissonMultiLock#tryLock(long, long, java.util.concurrent.TimeUnit)
在加锁的时候，会调用到这个方法，这里入参的意思分别是：
第一个waitTime是锁等待时间
leaseTime是锁加锁时间
TimeUnit是时间单位

我的理解是：线程A在加锁的时候，会使用leaseTime作为锁失效时间，如果没有指定，就是默认30S，然后进行锁续期；如果指定了，那就使用指定的阈值，并且不会自动化续期
线程B来加锁的时候，如果线程A已经对同一个key进行了加锁，那线程B最多等待waitTime时间，如果到了这个时间，线程B依旧没有获取到锁，那线程B加锁的方法就会返回false，表示加锁失败

一、最外层逻辑判断

public boolean tryLock(long waitTime, long leaseTime, TimeUnit unit) throws InterruptedException {
   
    long newLeaseTime = -1;
    // 1.这里是在指定了加锁时间，会将新的加锁时间设置为锁等待时间的2倍；这里我没怎么理解为什么要这么做，这里也是之前踩过的一个坑
    if (leaseTime != -1) {
   
        newLeaseTime = unit.toMillis(waitTime)*2;
    }
    
    long time = System.currentTimeMillis();
    long remainTime = -1;
    // 2.如果waitTime不等于-1，就是指定了等待时间的场景下，将等待时间转换为毫秒
    if (waitTime != -1) {
   
        remainTime = unit.toMillis(waitTime);
    }

    // 3.这里的计算，会用remainTime / Redis机器的数量；所以：如果我指定的等待时间是2000ms，那这里获取到的lockWaitTime就是666ms
    long lockWaitTime = calcLockWaitTime(remainTime);
    
    int failedLocksLimit = failedLocksLimit();
    List<RLock> acquiredLocks = new ArrayList<RLock>(locks.size());
    // 4.对所有的Redis节点进行遍历，然后依次去加锁，如果加锁失败的话，会进行一些列的处理；这里加锁失败的处理逻辑我还没有细看，后面再补充
    for (ListIterator<RLock> iterator = locks.listIterator(); iterator.hasNext();) {
   
        RLock lock = iterator.next();
        boolean lockAcquired;
        try {
   
        	// 4.1 如果等待时间未指定、锁超时时间未指定，那就调用下面这个方法即可，这个方法就和redissonLock加锁是一样的
            if (waitTime == -