Redisson分布式锁之公平锁原理
1、基本配置
配置信息与 Redisson分布式锁之非公平锁原理 配置一样，可自行查看
2、使用
与非公平锁不同的是，公平锁获取所对象时，使用的是 getFairLock 方法，返回的对象为 RedissonFairLock
RedissonFairLock 其实是 RedissonLock 的子类，它主要是基于 RedissonLock 做的扩展，主要扩展在于加锁和释放锁的地方，其他的逻辑都直接复用 RedissonLock，例如加锁前计算slot、watchdog机制等等。
// 1、获取key为"fairLock"的锁对象
RLock lock = redissonClient.getFairLock("fairLock");
// 2、加锁
lock.lock();
try {
// 进行具体的业务操作
...
} finally {
// 3、释放锁
lock.unlock();
}
3、加锁
首先看下 RLock lock = redissonClient.getFairLock("fairLock") 进行了哪些操作
public RLock getFairLock(String name) {
// 初始一个RedissonFairLock对象，构造方法中初始一些参数信息
return new RedissonFairLock(commandExecutor, name);
}
public RedissonFairLock(CommandAsyncExecutor commandExecutor, String name, long threadWaitTime) {
super(commandExecutor, name);
this.commandExecutor = commandExecutor;
// 线程等待时间 60000 * 5
this.threadWaitTime = threadWaitTime;
// redis list类型的key，用于保存获取锁的线程，此时为 redisson_lock_queue:{fairLock}
this.threadsQueueName = prefixName("redisson_lock_queue", name);
// redis zset类型的key，用于保存预计获取到锁的时间点，此时为 redisson_lock_timeout:{fairLock}
this.timeoutSetName = prefixName("redisson_lock_timeout", name);
}
后续的操作跟 Redisson分布式锁之非公平锁原理 一致
着重看一下 RedissonFairLock#tryLockInnerAsync 方法，里面有两段 lua 脚本，根据代码流程只需要关注第二段即可
由于lua基本过长，所以针对每一个分支进行分析
3.1 参数说明
KEYS = Arrays.asList(getRawName(), threadsQueueName, timeoutSetName)
- KEYS[1]：getRawName()，就是key的名称，也就是获取锁对象时设置的"fairLock"
- KEYS[2]：threadsQueueName，获取锁等待队列名称，redisson_lock_queue:{fairLock}
- KEYS[3]：timeoutSetName，等待队列中线程预计获取锁时间的 set 集合，按照时间戳存放，redisson_lock_timeout:{fairLock}
ARGV = unit.toMillis(leaseTime), getLockName(threadId), wait, currentTime
- ARGV[1]：unit.toMillis(leaseTime)，锁过期时间，其实就是watchdog超时时间，默认 30*1000 ms
- ARGV[2]：getLockName(threadId)，UUID:ThreadId，UUID来唯一标识一个客户端
- ARGV[3]：wait，也就是threadWaitTime，默认 5*60000 ms
- ARGV[4]：currentTime，当前时间戳
3.2 lua脚本分析
分支一：清理过期的等待线程
// remove stale threads
// 这个死循环主要作用是删除失效的线程
"while true do " +
// 获取等待队列第一个元素，就是第一个等待线程
// lindex redisson_lock_queue:{fairLock} 0 返回值其实就是 UUID:threadId
"local firstThreadId2 = redis.call('lindex', KEYS[2], 0);" +
// 如果为空，则跳出循环
"if firstThreadId2 == false then " +
"break;" +
"end;" +
// 获取第一个线程的分值(也就是超时时间) zscore redisson_lock_timeout:{fairLock} UUID:threadId
"local timeout = tonumber(redis.call('zscore', KEYS[3], firstThreadId2));" +
// 如果小于当期时间，说明已经失效，首先从超时集合中移除该节点，接着从等待队列中弹出第一个节点，否则退出循环
"if timeout <= tonumber(ARGV[4]) then " +
// remove the item from the queue and timeout set NOTE we do not alter any other timeout
// zrem redisson_lock_timeout:{fairLock} UUID:threadId
"redis.call('zrem', KEYS[3], firstThreadId2);" +
// lpop redisson_lock_queue:{fairLock}
"redis.call('lpop', KEYS[2]);" +
"else " +
"break;" +
"end;" +
"end;" +
场景：这个死循环的作用主要用于清理过期的等待线程，主要避免下面场景，避免无效客户端占用等待队列资源
-
获取锁失败，然后进入等待队列，但是网络出现问题，那么后续很有可能就不能继续正常获取锁了。
-
获取锁失败，然后进入等待队列，但是之后客户端所在服务器宕机了。
分支二：检查是否可成功获取锁
// check if the lock can be acquired now
// 如果当前锁为空，同时 （队列为空 或者 队列第一个线程是当前线程）
"if (redis.call('exists', KEYS[1]) == 0) " +
"and ((redis.call('exists', KEYS[2]) == 0) or (redis.call('lindex', KEYS[2], 0) == ARGV[2])) then " +
// remove this thread from the queue and timeout set
// 条件成立，则从队列和集合中删除当前线程
// lpop redisson_lock_queue:{myLock}：弹出等待队列中的第一个元素，即当前线程
// zrem redisson_lock_timeout:{myLock} UUID:threadId：从超时集合中移除当前客户端当前线程
"redis.call('lpop', KEYS[2]);" +
"redis.call('zrem', KEYS[3], ARGV[2]);" +
// decrease timeouts for all waiting in the queue
// 获取并遍历集合中所有的线程，每个线程的超时时间都减去5*60000ms
// zrange redisson_lock_timeout:{fairLock} 0 -1 从超时集合中获取所有的元素
"local keys = redis.call('zrange', KEYS[3], 0, -1);" +
"for i = 1, #keys, 1 do " +
// zincrby redisson_lock_timeout:{fairLock} -5*60000ms keys[i]
"redis.call('zincrby', KEYS[3], -tonumber(ARGV[3]), keys[i]);" +
"end;" +
// acquire the lock and set the TTL for the lease
// 当前线程获取到锁，并设置过期时间，默认是30s
// hset fairLock UUID:threadId 1
"redis.call('hset', KEYS[1], ARGV[2], 1);" +
// pexpire fairLock 30*1000ms
"redis.call('pexpire', KEYS[1], ARGV[1]);" +
"return nil;" +
"end;" +
场景：
-
其他客户端刚释放锁，并且等待队列为空
-
其他客户端刚释放锁，并且等待队列中的第一个元素就是当前客户端当前线程
TIPS：上述lua脚本中，有一段当某个线程获取到锁，为什么要扣减等待时间？
因为这里的客户端都是调用 lock()方法，就是等待直到最后获取到锁；所以某个客户端可以成功获取锁的时候，要帮其他等待的客户端刷新一下等待时间，不然在分支一的死循环中就被干掉了。
分支三：当前线程曾经获取锁，重复获取锁
// 如果当前线程已经获取到锁，则value+1（可重入）。同时重新设置过期时间
"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;" +
分支四：当前线程本就在等待队列中，返回等待时间
// the lock cannot be acquired, check if the thread is already in the queue
// 获取不到锁，如果当前线程已经在队列里面，返回 超时时间 - 等待时间(5*60000ms) - 当前时间
"local timeout = redis.call('zscore', KEYS[3], ARGV[2]);" +
"if timeout ~= false then " +
// the real timeout is the timeout of the prior thread in the queue, but this is approximately correct, and
// avoids having to traverse the queue
"return timeout - tonumber(ARGV[3]) - tonumber(ARGV[4]);" +
"end;" +
分支五：当前线程首次尝试获取锁，将当前线程加入到超时集合中，同时放入等待队列中
// add the thread to the queue at the end, and set its timeout in the timeout set to the timeout of // the prior thread in the queue (or the timeout of the lock if the queue is empty) plus the threadWaitTime // 获取到队列最后一个线程 // lindex redisson_lock_queue:{fairLock} -1 "local lastThreadId = redis.call('lindex', KEYS[2], -1);" + "local ttl;" + // 如果最后一个线程存在，且不是当前线程的话，ttl就等于最后一个线程的超时时间 - 当前时间，否则为fairLock的剩余生存时间 "if lastThreadId ~= false and lastThreadId ~= ARGV[2] then " + "ttl = tonumber(redis.call('zscore', KEYS[3], lastThreadId)) - tonumber(ARGV[4]);" + "else " + "ttl = redis.call('pttl', KEYS[1]);" + "end;" + // 计算超时时间，并将当前线程放入超时集合和等待队列中 // timeout = ttl + 线程等待时间(5*60000ms) + 当前时间戳 "local timeout = ttl + tonumber(ARGV[3]) + tonumber(ARGV[4]);" + // zadd redisson_lock_timeout:{fairLock} timeout UUID:threadId "if redis.call('zadd', KEYS[3], timeout, ARGV[2]) == 1 then " + // rpush redisson_lock_queue:{fairLock} UUID:theadId "redis.call('rpush', KEYS[2], ARGV[2]);" + "end;" + // 返回 ttl "return ttl;"
至此，整个获取锁的流程结束，从上述lua脚本可以看出，有一个hash结构的锁，一个存放获取锁线程的list队列redisson_lock_queue:{fairLock}，一个存放等待队列中线程预计获取锁时间的zset集合redisson_lock_timeout:{fairLock}，最终存在redis中的数据为：
Hash结构的锁 fairLock
List结构的队列 redisson_lock_queue:{fairLock}
Zset结构的集合 redisson_lock_timeout:{fairLock}
3.3 获取锁成功
获取锁成功后，后续操作锁的续期(看门狗线程)，与非公平锁(RedissonLock) 的操作是一样的
3.4 获取锁失败
如果没有获取到锁的线程，与RedissonLock一致的操作，也是在redis中发布订阅消息，等待释放锁的线程发布通知，不过此时订阅的通道有所不同，RedissonFairLock 公平获取锁，即先到先得。所以每个等待线程订阅的channel时不同的：redisson_lock__channel:{fairLock}:UUID:threadId。当某个线程释放锁的时候，只会往等待队列中第一个线程对应订阅的channel发送消息，在释放锁的lua脚本中会向通道中发布消息
protected RFuture<RedissonLockEntry> subscribe(long threadId) { // 订阅的通道：redisson_lock__channel:{fairLock}:UUID:threadId return pubSub.subscribe(getEntryName() + ":" + threadId, getChannelName() + ":" + getLockName(threadId)); }
查看一下订阅的通道信息，可使用命令 PUBSUB CHANNELS
事件订阅完成后，同样会进入while (true)死循环中，进行阻塞获取锁
4、释放锁
释放锁是在 RedissonFairLock#unlockInnerAsync 中执行lua脚本，因为加入了公平获取锁的机制，所以lua脚本还是挺长的，依旧是针对每一个分支进行分析
4.1 参数说明
KEYS = Arrays.asList(getRawName(), threadsQueueName, timeoutSetName, getChannelName())
- KEYS[1]：getRawName()，就是key的名称，也就是获取锁对象时设置的"fairLock"
- KEYS[2]：threadsQueueName，获取锁等待队列名称，redisson_lock_queue:{fairLock}
- KEYS[3]：timeoutSetName，等待队列中线程预计获取锁时间的 set 集合，按照时间戳存放，redisson_lock_timeout:{fairLock}
- KEYS[4]：getChannelName()，当前锁对应的订阅channel，redisson_lock__channel:{fairLock}:UUID:threadId
ARGV = LockPubSub.UNLOCK_MESSAGE, internalLockLeaseTime, getLockName(threadId), System.currentTimeMillis()
- ARGV[1]：LockPubSub.UNLOCK_MESSAGE，Redis发布事件时的message，为0
- ARGV[2]：internalLockLeaseTime，watchdog的超时时间，30*1000 ms
- ARGV[3]：getLockName(threadId)，UUID:ThreadId，UUID来唯一标识一个客户端
- ARGV[4]：System.currentTimeMillis()，当前时间戳
4.2 lua脚本分析
分支一：清理过期的等待线程
和获取锁的第一步一样，开个死循环清理过期的等待线程，避免无效客户端占用等待队列资源
// remove stale threads
// 这个死循环主要作用是删除失效的线程
"while true do " +
// 获取等待队列第一个元素，就是第一个等待线程
// lindex redisson_lock_queue:{fairLock} 0 返回值其实就是 UUID:threadId
"local firstThreadId2 = redis.call('lindex', KEYS[2], 0);" +
// 如果为空，则跳出循环
"if firstThreadId2 == false then " +
"break;" +
"end;" +
// 获取第一个线程的分值(也就是超时时间) zscore redisson_lock_timeout:{fairLock} UUID:threadId
"local timeout = tonumber(redis.call('zscore', KEYS[3], firstThreadId2));" +
// 如果小于当期时间，说明已经失效，首先从超时集合中移除该节点，接着从等待队列中弹出第一个节点，否则退出循环
"if timeout <= tonumber(ARGV[4]) then " +
// remove the item from the queue and timeout set NOTE we do not alter any other timeout
// zrem redisson_lock_timeout:{fairLock} UUID:threadId
"redis.call('zrem', KEYS[3], firstThreadId2);" +
// lpop redisson_lock_queue:{fairLock}
"redis.call('lpop', KEYS[2]);" +
"else " +
"break;" +
"end;" +
"end;" +
分支二：锁已经被释放，通知等待队列中第一个线程
// 判断锁是否存在，exists fairLock
"if (redis.call('exists', KEYS[1]) == 0) then " +
// 如果不存在，则获取等待队列中的第一个元素，lindex redisson_lock_queue:{fairLock} 0
"local nextThreadId = redis.call('lindex', KEYS[2], 0); " +
"if nextThreadId ~= false then " +
// 如果等待列表中第一个元素不为空，即还存在等待线程，往等待线程的订阅channel发送消息，通知其可以尝试获取锁了
// publish redisson_lock__channel:{fairLock}:UUID:threadId 0
"redis.call('publish', KEYS[4] .. ':' .. nextThreadId, ARGV[1]); " +
"end; " +
"return 1; " +
"end;" +
场景：
-
成功获取锁线程重复调用释放锁的方法，第二次释放时，锁已不存在，就去通知等待队列中的第一个元素
-
又或者一个极端场景：当前线程未能成功获取锁，但是调用了释放锁的方法，并且刚好此时锁被释放
分支三：加锁记录中的线程不是当前线程
// 判断加锁记录集合中，是否存在当前客户端当前线程
// hexists fairLock UUID:threadId
"if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " +
// 加锁记录不存在当前线程，返回nil
"return nil;" +
"end; " +
场景：
-
当前线程未能成功获取锁，但是调用了释放锁的方法
分支四：当前线程拥有锁，并且获取锁次数大于1
// 利用 hincrby 扣减当前线程的加锁次数
// hincrby fairLock UUID:threadId -1
"local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " +
// 如果扣减后次数还是大于0，证明是重入锁，所以此时只需要重新刷新锁的过期时间
"if (counter > 0) then " +
// expire fairLock 30000
"redis.call('pexpire', KEYS[1], ARGV[2]); " +
"return 0; " +
"end; " +
分支五：当前线程成功释放锁
// 利用 del 命令删除锁对应 redis key，del fairLock
"redis.call('del', KEYS[1]); " +
// 获取等待队列中的第一个元素，lindex redisson_lock_queue:{fairLock} 0
"local nextThreadId = redis.call('lindex', KEYS[2], 0); " +
// 如果不为null，则发布个事件 redisson_lock__channel:{anyLock}:UUID:threadId
"if nextThreadId ~= false then " +
// publish redisson_lock__channel:{fairLock}:UUID:threadId 0
"redis.call('publish', KEYS[4] .. ':' .. nextThreadId, ARGV[1]); " +
"end; " +
"return 1; "
至此，如果释放锁成功，则后续的操作：例如停止watchdog运行(锁的续期)，事件发布订阅操作等，都跟RedissonLock的操作保持一致
