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通信的网络的一个问题，延迟，各种情况都可能会发生
客户端释放锁，释放锁之后队列中的排队的客户端是如何依次获取这把锁的，是按照队列里的顺序去获取锁的