在使用分布式锁进行互斥资源访问时候，我们很多方案是采用redis的实现。
固然，redis的单节点锁在极端情况也是有问题的，假设你的业务允许偶尔的失效，使用单节点的redis锁方案就足够了，简单而且效率高。
redis锁失效的情况：
客户端1从master节点获取了锁master宕机了，存储锁的key还没来得及同步到slave节点上slave升级为master客户端2从新的master上获取到同一个资源的锁于是，客户端1和客户端2同事持有了同一个资源的锁，锁的安全性被打破。
如果我们不考虑这种极端情况，需要实现一个基于单节点redis锁的大致流程：
setcache_keyrandom_seedNXPX
上面这个set命令拆解开就是：
setnxcache_keyrandom_seedexpirecache_key30
虽然这两组命令执行的效果一样，但是第二个是非原子性操作，如果执行了setnx成功，但是expire失败的话，就会造成这个key一直存在了，无法释放的情况。
Redis深度历险核心原理与应用实践Redis中间件运维Redis技术应用原京东查看已下架redis的作者也指出，在使用单节点redis锁的时候，设置一个随机种子作为key的值是很有必要的，保证了一个客户端释放的锁必须是自己所持有的那个锁。假设获取锁时set的不是一个随机数，而是一个固定值，那么可能会出现下面的情况：
客户端1获取锁成功客户端1在某个操作上阻塞了很长时间过期时间到了，锁自动释放（但是在客户端1看来自己还是持有锁中）客户端2获取到了对应同一个资源的锁客户端1从阻塞中恢复了，释放掉自己持有的锁，也就是释放掉了客户端2持有的锁客户端2的锁被客户端1是否，失去安全性。
释放锁的操作，很多人直接用del命令，这会有很大的问题，保证不了这个key是被加锁人锁删。这时候需要用到随机数了。释放锁的操作有三步：
get所持有锁判断这个锁是否自己所持有删除持有锁所以，这三步要保证原子性。用lua脚本来执行，redis官方已经提供脚本文件。
这段脚本在执行的时候，需要把前面的随机数作为argv[1]的值传进去，把cache_key作为keys[1]的值传进去。
r2mClusterClient就是jedis客户端的封装。