分布式锁: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续约

加锁的整体步骤

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

里面引入了一个信号量

思考

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

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