了解Redis锁（二）

介绍 Redisson 之前，笔者简单解释一下为什么现在的 Setnx 默认是指 Set 命令带上 NX 参数，而不是直接说是 Setnx 这个命令。
 
因为 Redis 版本在 2.6.12 之前，Set 是不支持 NX 参数的，如果想要完成一个锁，那么需要两条命令：
1. setnx Test uuid
2. expire Test 30
 
即放入 Key 和设置有效期，是分开的两步，理论上会出现 1 刚执行完，程序挂掉，无法保证原子性。
 
但是早在 2013 年，也就是 7 年前，Redis 就发布了 2.6.12 版本，并且官网(Set 命令页)，也早早就说明了“SETNX，SETEX，PSETEX 可能在未来的版本中，会弃用并永久删除”。
笔者曾阅读过一位大佬的文章，其中就有一句指导入门者的面试小套路，具体文字忘记了，大概意思如下：说到 Redis 锁的时候，可以先从 Setnx 讲起，最后慢慢引出 Set 命令的可以加参数，可以体现出自己的知识面。
 
如果有缘你也阅读过这篇文章，并且学到了这个套路，作为本文的笔者我要加一句提醒：请注意你的工作年限！首先回答官网表明即将废弃的命令，再引出 Set 命令七年前的“新特性”，如果是刚毕业不久的人这么说，面试官会以为自己穿越了。

你套路面试官，面试官也会套路你。  -- vt・沃兹基硕德

Redisson

Redisson 是 Java 的 Redis 客户端之一，提供了一些 API 方便操作 Redis。

但是 Redisson 这个客户端可有点厉害，笔者在官网截了仅仅是一部分的图：



这个特性列表可以说是太多了，是不是还看到了一些 JUC 包下面的类名，Redisson 帮我们搞了分布式的版本。
 
比如 AtomicLong，直接用 RedissonAtomicLong 就行了，连类名都不用去新记，很人性化了。
 
锁只是它的冰山一角，并且从它的 Wiki 页面看到，对主从，哨兵，集群等模式都支持，当然了，单节点模式肯定是支持的。
 
本文还是以锁为主，其他的不过多介绍。Redisson 普通的锁实现源码主要是 RedissonLock 这个类，还没有看过它源码的盆友，不妨去瞧一瞧。
 
源码中加锁/释放锁操作都是用 Lua 脚本完成的，封装的非常完善，开箱即用。这里有个小细节，加锁使用 Setnx 就能实现，也采用 Lua 脚本是不是多此一举？
 
笔者也非常严谨的思考了一下：这么厉害的东西哪能写废代码？



其实笔者仔细看了一下，加锁解锁的 Lua 脚本考虑的非常全面，其中就包括锁的重入性，这点可以说是考虑非常周全，我也随手写了代码测试一下：




的确用起来像 JDK 的 ReentrantLock 一样丝滑，那么 Redisson 实现的已经这么完善，RedLock 又是什么？
 
RedLock



RedLock的中文是直译过来的，就叫红锁。红锁并非是一个工具，而是 Redis 官方提出的一种分布式锁的算法。
 
就在刚刚介绍完的 Redisson 中，就实现了 RedLock 版本的锁。也就是说除了 getLock 方法，还有 getRedLock 方法。
 
大概画了一下对红锁的理解：



如果你不熟悉 Redis 高可用部署，那么没关系。RedLock 算法虽然是需要多个实例，但是这些实例都是独自部署的，没有主从关系。
RedLock 作者指出，之所以要用独立的，是避免了 Redis 异步复制造成的锁丢失，比如：主节点没来的及把刚刚 Set 进来这条数据给从节点，就挂了。
 
有些人是不是觉得大佬们都是杠精啊，天天就想着极端情况。其实高可用嘛，拼的就是 99.999...% 中小数点后面的位数。
 
回到上面那张简陋的图片，红锁算法认为，只要 2N+1 个节点加锁成功，那么就认为获取了锁， 解锁时将所有实例解锁。

流程为：

• 顺序向五个节点请求加锁
• 根据一定的超时时间来推断是不是跳过该节点
• 三个节点加锁成功并且花费时间小于锁的有效期
• 认定加锁成功

 
也就是说，假设锁 30 秒过期，三个节点加锁花了 31 秒，自然是加锁失败了。
 
这只是举个例子，实际上并不应该等每个节点那么长时间，就像官网所说的那样，假设有效期是 10 秒，那么单个 Redis 实例操作超时时间，应该在 5 到 50 毫秒(注意时间单位)。
 
还是假设我们设置有效期是 30 秒，图中超时了两个 Redis 节点。那么加锁成功的节点总共花费了 3 秒，所以锁的实际有效期是小于 27 秒的。
 
即扣除加锁成功三个实例的 3 秒，还要扣除等待超时 Redis 实例的总共时间。看到这，你有可能对这个算法有一些疑问，那么你不是一个人。
 
回头看看 Redis 官网关于红锁的描述，就在这篇描述页面的最下面，你能看到著名的关于红锁的神仙打架事件。



即 Martin Kleppmann 和 Antirez 的 RedLock 辩论。一个是很有资历的分布式架构师，一个是 Redis 之父。
官方挂人，最为致命。开个玩笑，要是质疑能被官方挂到官网，说明肯定是有价值的。
 
所以说如果项目里要使用红锁，除了红锁的介绍，不妨要多看两篇文章，即：

• Martin Kleppmann 的质疑贴
• Antirez 的反击贴