Redis分布式锁（二次更新，框架演进过程中的收获）

首先，先附上之前的文章（Redis实现分布式锁），实话说，当时了解的好像不太透彻，或者是时间长了，就有点忘了，总之，重新记录一下，慢慢回忆！

总结一下在框架演进过程中，我所碰到的问题，以及我解决问题的想法，和最后使用的解决策略。

Redis分布式锁流程图

先解释一下上面的这这张图，通过setnx设置lockKey,value值为当前时间（currenttime）加上超时时间（timeout）

这里先提前说一下，可以了解到，在这张图上，setnx设置的value值没有使用到（在项目演进的时候会用到，所以要提前准备好）。纯粹的就是设置了一个锁。

在分布式的环境下，一个tomcat如果获取锁成功，就会执行左侧那些业务，而此时，另一个tomcat获取这个锁的时候就会返回0，即获取锁失败

对于setnx命令，请参考我之前的文章，上面提到过

可以看出，上述的流程图有很大的缺陷，所以，继续下面的图！

解释一下这张经过优化的图！，

首先，setnx执行后，返回1，获取锁之后的业务执行不变

改变的是针对未获取锁的时候的判断，这里就会用上setnx设置的value值了。

如果setnx失败，就执行get方法，这样，我们就能拿到setnx执行后时设置的value值，即（currenttime+timeout）

然后，再做判断，我们将从get方法中拿到的value值设置为lockValueA，

进行判断，判断lockValueA是否为空，并且，当前的时间是否大于lockValueA（即最开始setnx设置时的currenttime+timeout）

也就是说setnx的时候，这个lockKey的timeout已经超时了，另一个tomcat时是有权利获取锁的，

如果这个条件满足的话，就是跳到getset的分支上，key仍然是之前的key，只不过将value值重新设置为此时的当前时间+timeout时间，（这里注意，不要弄混这两个currenttime，一个是上一个时间点的当前时间，一个是现在时间点的当前时间）

所以，getset方法会返回一个lockValueB，

如果lockValueB等于null的话，那就代表，lockKey已经没有了，另一个tomcat就可以获取这个锁了，

又或者lockValueA和lockValueB相等的话，就代表最新获取到的lockValueB和之前get获取到的lockValueA如果相等，就代表在这个过程中，这个锁其实是没有变化的，如果这个条件满足，则为true，则获取锁成功，继续执行左侧的那些业务，否则，为false，那就结束了这个分布式锁。