万剑归宗，redisson的百锁解构（上）

万剑归宗，剑至高境，剑谱上虽是普通招式，可是练至大成，以指为剑，剑气破苍穹。redisson框架也是如此，通过lua脚本实现了可重入非公平锁，公平锁，非公平锁，联合锁，信号量，读写锁，countDownLatch，甚至redlock算法也巧妙实现。今天这篇文章，就以我个人的理解去解构这些锁的实现，redisson封装的很好，类的结构很清晰，所有加锁解锁的逻辑都写在了lua脚本中，对于我们使用者而言，也像那本简单的剑谱一样，简单招式，却能爆发出巨大的威力。

可重入锁的分析我们已经在之前的文章做了具体的分析，参见【扒开Redisson的小棉袄，Debug深入剖析分布式锁之可重入锁No.1】，对于watchdog的运行机制之前也做了详细的分析，这里可以再回顾一遍，【汪~汪~汪~redisson的WatchDog是如何看家护院的？】，相信这一招式大家都已经领悟，其实后面的各种锁的招式都有这招的影子，一生二，二生三，最终万千变化。得益于redisson的良好封装，我们可以清晰愉快地接下去分析各类锁的逻辑。

招式一  【公平锁】

公平锁，顾名思义，和非公平锁最大的区别就是每次获取锁的客户端会按照之前获取锁的先后顺序进行排队，当持有锁的客户端释放的时候，先入队的客户端，先去获取锁。我们先找到源码中加锁的核心逻辑，如下图所示：

首先映入眼帘的是一个while(true)的无限循环，通过lindex,zscore俩个命令，可以分析出，这里使用了redis的数据结构 有序集合(sorted set)和队列(List)，我们往下接着看，看看是如何使用这俩种结构的；首先判断是否存在这个锁key，假设为anylock,并且该锁对应的队列不存在，说明该客户端还没有加过锁，那么就可以执行加锁逻辑啦,和之前的加锁逻辑也差不多，只是多了删除队列和有序集合中对应数据的操作，其他的还是通过hset设置37f75873-494a-439c-a0ed-f102bc2f3204:1 值为1，并且设置过期时间为30000毫秒，然后就返回nil了，接下来也是一样，watchdog会通过定时任务去做续期操作。

【 入队 】当第二个客户端来尝试加锁的时候，还是先经过无限循环，此时队列还是为空，直接break;然后接下来的逻辑就是计算超时时间timeout的逻辑，此时获取到anyLock的剩余有效时间10000毫秒，通过公式 ttl+当前时间+固定等待时间5000毫秒算出超时时间,然后就是入队逻辑啦，先是zadd进入有序队列，有序队列的score就是超时时间的时间戳，按照从小到大的顺序排列，保证先后顺序，接着又在队列的队尾插入37f75873-494a-439c-a0ed-f102bc2f3204:1，返回剩余时间ttl。那么第二个客户端就会进入不断尝试加锁的逻辑，等待持有锁的客户端释放。

【 排队&分数刷新 】好当第三个客户端来尝试加锁的时候，就会进入排队逻辑，这个时候我们看到其实开头的无限循环，就是每次去检查队列第一个元素的超时时间是否大于当前时间，如果大于当前时间，就会删除队列和有序集合中对应的数据。接着往下走，和之前的逻辑一样经过几个条件判断之后，计算超时时间【采用第一个元素的超时时间-当前时间】，往有序集合和队列中写入数据，进行排队。对于客户端的不断尝试，会让每次没有加锁成功的客户端刷新自己在有序队列中的timeout时间，但是因为每个锁都会越来越大，所以顺序大概率是不会变，除非某个客户端发生了故障导致延长，可能会导致重排。

【 重排&释放 】当第一个客户端释放锁的时候，还是会通过上面的逻辑去判断队列的第一个元素，当其超时时间满足条件，就会执行加锁逻辑。对于维持的加锁排队队列来说，其中通过每次的循环判断会去处理已经超时的元素，这样就可以保证在可能的网络延迟或者客户端故障长时间没有释放锁导致的队列元素堆积不会发生。

【 可重入 】到这里，对于公平锁的关键排队机制，我们了解，从上面图中的源码我们也可以看到，公平锁也是支持可重入的，当同一个客户端的同一个线程进行加锁的时候，也会和之前的不公平可重入锁一样，累加锁key的值hincrby操作，OK，这些就是公平锁的招式拆解啦。

招式二    【 联合锁 】

联合锁，多个锁，不知道这么翻译multiLock合不合适，大白话来说，就是申请多个小锁，合并成一个大锁，并且要保证这多个小锁都要在规定时间内要加锁成功，才算加锁成功，进行业务逻辑处理，最后也是要依次释放所有的锁。这里分析的就是java代码啦，不是lua脚本，由此可见，

这个联合锁也是对原来我们分析的基础锁进行了一些高级封装，从而达到了multiLock的效果。假设我们先是使用了三个小锁进行联合，这边主要就是会计算waitTime，基本等待时间baseWaitTime就是4500毫秒，当leaseTime为-1的时候，waitTime=baseWaitTime=4500毫秒，如果不是就会计算waitTime的值，然后就是进入一个无限循环，去尝试加锁，逻辑如下：

    接着又配置了一个remainTime=waitTime=4500毫秒，有个关键参数failedLocksLimit,加锁失败限制次数，在这里值为0，不允许有失败；下面就是循环遍历之前我们传入进来的小锁，每一把锁都去尝试获取锁，使用tryLock(),一旦4500毫秒没有获取到锁，就会返回，将lockAcquire标识为false。这里有个小细节，newLeaseTime为-1，就是说如果尝试获取到锁了，那么会有watchdog机制去延长锁的有效期。接下来就会判断 加锁成功就会加入到加锁成功的队列里面，如果失败就会判断当前锁的size-成功加锁的size==加锁失败次数，如果相等就break；否则判断是否为0，在这里是不可能为零了吗所以会进行锁释放，以及各种参数的复位操作，如果不为0，就将failedLockLimit--;

这里将会判断当前时间减去加锁开始时间得到加锁总耗时和我们之前的remainTime=4500毫秒进行比较，如果超过了，也会去释放锁，并且返回false；也就是说所有的小锁加锁要在规定的时间内加锁完成，否则就会再次回到无限循环那里，继续进行尝试加锁，释放锁的逻辑呢，更加清晰，就是依次释放锁。

招式三【 RedLock 】

RedLock算法，是redis官方作者提出来的一套基于redis集群生成的分布式锁算法，总结来说，就是每次获取锁，不是只对其中一台master进行获取锁操作，而是每次获取锁都要在集群大部分master【集群master数量n/2+1台实例】上成功获取到锁，并且要在规定的时间内获取到锁。如果这套机制我们自己来写，那肯定是相当复杂的。但是redisson作者却使用了相当巧妙的方法去实现了，就是用上面multiLock的机制去实现他，联合锁的思想就是获取多个锁合并一个大锁，那么我们是不是也可以这样子，获取的多个大锁就是从redis集群不同的master实例上去获取就可以了，OK，我们来看代码，

从代码来看很有趣吧，RedissonRedLock是RedissonMultiLock的子类，只是重载了一些父类的方法，失败次数计算，最新锁获取个数，还有计算等待时间这些，并且类似你使用lock1,lock2,lock3进行加锁，就是会分布到三台不同的master实例上，配合multiLock机制 以及已上的参数修改，就妥妥实现RedLock机制啦。