redis面试（十五）公平锁队列重排

队列重拍

先说一下当前的加锁状态

• anyLock由客户端A持有
• 队列中是客户端B、客户端C
• 并且客户端B现在是排在头部

那么队列重拍就是队列中某个客户端长时间没有重新申请加锁，没有刷新分数，就会被队列中挤掉。
假设这个长时间没有加锁的客户端是B。

总结

分析代码有些啰嗦，所以先总结流程：

• 客户端B长时间没有加锁，没有刷新时间分数
• 客户端C加锁刷新之后，分数超过了B
• 那就将客户端B的线程从队列中移除，客户端 C变成头部
• 客户端B如果再次申请加锁的话，会排在C的后面
• 这个就是队列重排

过程

恍恍惚惚的，又行进到了10:00:36秒，客户端C来进行的重新尝试进行加锁，此时客户端B他其实在这之前不知道可能因为网络原因或者是别的什么原因，可能他就是没有尝试过重新加锁

进入while true，拿到队列第一个元素的timeout时间，10:00:30 <= 10:00:36，条件成立

zrem redisson_lock_timeout:{anyLock} UUID_02:threadId_02，就从有序集合中将客户端B移除了，lpop redisson_lock_queue:{anyLock}，就从队列中将客户端B也移除了

此时队列的第一个元素是客户端C，他的timeout时间是10:00:35 <= 10:00:36，条件成立，从有序集合以及队列中删除掉客户端C

尝试进行加锁，不成立，因为客户端A还持有着那把锁

重新排队入队，pttl anyLock = 23000毫秒
ttl = 23000毫秒
timeout = 23000毫秒 + 10:00:36 + 5000毫秒 = 10:01:04

zadd和rpush两个指令，将客户端C压入队列和有序集合中

假设此时，在10:00:38，客户端B再次尝试来进行加锁，while true退出

尝试加锁，不成立

重新尝试入队

ttl = 10:01:04 - 10:00:38 = 26000毫秒
timeout = 26000毫秒 + 10:00:38 + 5000毫秒 = 10:01:09

zadd和rpush两个指令，重新尝试入队

从这个里面，我们可以看到，在一个客户端刚刚加锁之后，其他的客户端来争抢这把锁，刚开始在一定时间范围之内，时间不要过长，各个客户端是可以按照公平的节奏，在队列和有序集合里面进行排序

在一定时间范围内，时间不要过长，其实队列里的元素顺序是不会改变的，各个客户端重新尝试加锁，只不过是刷新有序集合中的分数（timeout），各个客户端的timeout不断加长，但是整体顺序大致还是保持一致的

但是如果客户端A持有的锁的时间过长，timeout，这个所谓的排队是有timeout，可能会在while true死循环中将一些等待时间过长的客户端从队列和有序集合中删除，一旦删除过后，就会发生各个客户端随着自己重新尝试加锁的时间次序，重新进行一个队列中的重排，也就是排队的顺序可能会发生变化

客户端跟redis通信的网络的一个问题，延迟，各种情况都可能会发生

客户端释放锁，释放锁之后队列中的排队的客户端是如何依次获取这把锁的，是按照队列里的顺序去获取锁的