分布式锁:Redisson源码解析——RLock（一）

初始化锁对象

RLock lock = redisson.getLock("anyLock");

RLock的整体类图

可以注意到，其实像RedissonFairLock等等都是继承的RedissonLock

初始化了一个RedissonLock的对象，里面有个核心就是命令执行器，需要额外关注的就是internalLockLeaseTime 和entryName

CommandAsyncExecutor

看意思这个是一个命令异步执行器

• slot：slot就是cluster中的槽

public int calcSlot(String key) {
    if (key == null) {
        return 0;
    }

    int start = key.indexOf('{');
    if (start != -1) {
        int end = key.indexOf('}');
        if (end != -1 && start + 1 < end) {
            key = key.substring(start + 1, end);
        }
    }

    int result = CRC16.crc16(key.getBytes()) % MAX_SLOT;
    log.debug("slot {} for {}", result, key);
    return result;
}

• NodeSource: 就是一个对象，基本可以代表将要连接的redis节点

加锁——ReentrantLock

lock.lock();

方法重载

第一次加锁及watchdog续约

加锁的整体步骤

1. 初始化数据的获取：threadId、connection manager uuid、leaseTime、lockName
   a. threadId
   b. uuid是从初始化getLock的时候就获取的
   c. leaseTime，可以提供参数，默认的是30s
2. 执行lua脚本
   a. 判断redis中是否有key存在
   b. 设置hash数据结构：lockName { uuid:threadId --> number }
   c. 设置lockName的过期时间是leaseTime
   d. 加锁成功返回nil，否则抛出异常或者是返回key的ttl
3. 如果加锁成功
   a. 维护了一个map { id:lockName : { {threadId:number},timeout } }
   b. 会开启一个调度任务， leaseTime/3 时间后执行
4. 执行lua脚本
   a. 判断Redis中存在lockName的hash结构的key–> uuid:threadId
   b. 存在就设置过期时间为leaseTime返回1，不存在直接返回0
   c. 返回1，则会递归再执行续约的方法，下一个时间点后再执行续约
   d. 如果不存在key，则本地的map里面的key也要去掉了

重点设计

连接发送

在初始化lock的时候，会根据lockName计算获取到slot，然后初始化一个nodesource，从而知道发送指令到哪一台机器上

public int calcSlot(String key) {
  if (key == null) {
      return 0;
  }

  int start = key.indexOf('{');
  if (start != -1) {
      int end = key.indexOf('}');
      if (end != -1 && start + 1 < end) {
          key = key.substring(start + 1, end);
      }
  }

  int result = CRC16.crc16(key.getBytes()) % MAX_SLOT; // 16384
  log.debug("slot {} for {}", result, key);
  return result;
}

数据结构

redis中的数据结构：

{
  "lockName": {
      "uuid:threadId": counter
  }
}

本地的数据结构：

{
  "uuid:lockName": {
    "threadIds": {
      "threadId": 1,
      "counter": 1
    },
    "timeout": timeout
  }
}

可以发现redis和本地存储的数据结构其实都是一个map，而且会在进行加锁的过程中进行一个数据的同步
● 加锁成功的时候，会往本地map中插入一个数据
● 如果续约的时候发现续约失败，就会将本地map中对应的数据给删除掉

watchdog

watchdog的出现，是为了避免如果客户端A持续持有锁而超过了锁的有效时间，导致redis中锁已经过期了，然后会有客户端B来加锁，导致的情况是两个客户端同时持有锁
● watchdog的核心原理是如果锁被持有那么锁的过期时间就重置
● 时间周期是leaseTime/3执行一次，并且如果续约成功就会递归再次执行续约
● 维护了一个本地的Map，代表的是需要去进行续约的lock

阻塞

在加锁的时候执行的lua脚本中，如果加锁失败，也就是key存在，但是里面的hash key不存在就属于其他线程来进行加锁，这个时候就需要进行互斥了
● lua脚本中会返回redis key 的ttl
● 加锁中如果感知到返回的是ttl，则会走一个无线循环来获取锁
● 里面引入了一个信号量

思考

1. 如果持续持有一把锁，这个锁的有效时间如何变化
   a. 锁的有效时间，会通过续约的定时任务来进行变化的，每leaseTime/3时间内就会续约一次
2. 释放锁之后，这个定时任务是如何的取消的
   a. 内部维护了一个需要续约的map，如果释放锁之后的话，只需要将本地map中的key移除掉即可
3. 如果持有锁的客户端宕机了，会发生什么样的情况
   a. 因为续约是发生在客户端的，如果客户端宕机了，只会阻塞30s之后，其他线程就可以来获取到锁
4. 如果某个机器上的某个线程，已经对key加锁了，那么这台机器上的其他线程如果尝试对key加锁，会怎么样？如何阻塞的？
   a. 如果是其他的线程获取锁会返回一个ttl，然后进入一个无限循环，来获取锁，同时也引入了信号量，提高效率和避免并发
5. 如果某个机器上的某个线程，已经对key加锁了，那么其他机器上的其他线程如果尝试对key加锁，会怎么样？如何阻塞的？
   a. 如果是其他的机器来进行加锁，会发现已经存在这个key了，但是对应的key里面的hash key UUID:threadId 却是不存在的，就会导致返回的是ttl，就与前面一致了
6. 如果设置了两个加锁的参数，是如何在一定时间之后，自动释放锁，如何控制获取锁超时
   a. 设置的参数本质上也就是LeaseTime，就不再说明了

这一篇，其实已经大体将redisson reentrantLock说明白了，下一篇主要是可重入、释放锁、锁超时和自动释放的源码