Redisson 分布式锁源码 09：RedLock 红锁的故事
前言
RedLock 红锁，是分布式锁中必须要了解的一个概念。
所以本文会先介绍什么是 RedLock，当大家对 RedLock 有一个基本的了解。然后再看 Redisson 中是如何实现 RedLock 的。
在文章开头先说明 Redisson RedLock 建议不要使用！！！
在文章开头先说明 Redisson RedLock 建议不要使用！！！
在文章开头先说明 Redisson RedLock 建议不要使用！！！
重要的事情重复三遍！
什么是 RedLock？
RedLock，这块可以从网上搜到很多资料，本文也简单介绍下，当做扫盲。
单实例加锁
SET resource_name my_random_value NX PX 30000
对于单实例 Redis 只需要使用这个命令即可。
- NX：仅在不存在 key 的时候才能被执行成功；
- PX：失效时间，传入 30000，就是 30s 后自动释放锁；
- my_random_value：就是随机值，可以是线程号之类的。主要是为了更安全的释放锁，释放锁的时候使用脚本告诉 Redis: 只有 key 存在并且存储的值和我指定的值一样才能删除成功。
可以通过以下 Lua 脚本实现锁释放：
if redis.call("get",KEYS[1]) == ARGV[1] then
return redis.call("del",KEYS[1])
else
return 0
end
为什么要设置随机值？
主要是为了防止锁被其他客户端删除。有这么一种情况：
- 客户端 A 获得了锁，还没有执行结束，但是锁超时自动释放了；
- 客户端 B 此时过来，是可以获得锁的，加锁成功；
- 此时，客户端 A 执行结束了，要去释放锁，如果不对比随机值，就会把客户端 B 的锁给释放了。
当然前面看过 Redisson 的处理，这个 my_random_value 存放的是 UUID:ThreadId 组合成的一个类似 931573de-903e-42fd-baa7-428ebb7eda80:1 的字符串。
当锁遇到故障转移
单实例肯定不是很可靠吧？加锁成功之后，结果 Redis 服务宕机了，这不就凉凉~
这时候会提出来将 Redis 主从部署。即使是主从，也是存在巧合的！
主从结构中存在明显的竞态：
- 客户端 A 从 master 获取到锁
- 在 master 将锁同步到 slave 之前，master 宕掉了。
- slave 节点被晋级为 master 节点
- 客户端 B 取得了同一个资源被客户端 A 已经获取到的另外一个锁。安全失效！
有时候程序就是这么巧，比如说正好一个节点挂掉的时候，多个客户端同时取到了锁。如果你可以接受这种小概率错误，那用这个基于复制的方案就完全没有问题。
那我使用集群呢？
如果还记得前面的内容，应该是知道对集群进行加锁的时候，其实是通过 CRC16 的 hash 函数来对 key 进行取模，将结果路由到预先分配过 slot 的相应节点上。
发现其实还是发到单个节点上的！
RedLock 概念
这时候 Redis 作者提出了 RedLock 的概念
总结一下就是对集群的每个节点进行加锁，如果大多数（N/2+1）加锁成功了，则认为获取锁成功。
RedLock 的问题
看着 RedLock 好像是解决问题了：
- 客户端 A 锁住了集群的大多数（一半以上）；
- 客户端 B 也要锁住大多数；
- 这里肯定会冲突，所以 客户端 B 加锁失败。
那实际解决问题了么？
推荐大家阅读两篇文章：
-
Martin Kleppmann：How to do distributed locking
-
Salvatore（Redis 作者）：Is Redlock safe?
最终，两方各持己见，没有得出结论。
鉴于本文主要是分析 Redisson 的 RedLock，就不做额外赘述，感兴趣的小伙伴可以自己阅读。
Redisson 中 RedLock 源码
这里会简要分析一下 Redisson 中 RedLock 的源码，然后会介绍为什么文章开头不建议大家使用 Redisson 的 RedLock。
使用方式
乍一看，感觉和联锁 MultiLock 的使用方式很像啊！
实际上就是很像，RedissonRedLock 完全是 RedissonMultiLock 的子类嘛！
只不过是重写 failedLocksLimit 方法。
在 MultiLock 中，要所有的锁都锁成功才可以。
在 RedLock 中，要一半以上的锁成功。
剩余部分源码都和 MultiLock 一样，就不在重复描述了。
Redisson 中 RedLock 的问题
1、加锁 key 的问题
阅读源码之前，有一个很大的疑问，我加锁 lock1、lock2、lock3，但是 RedissonRedLock 是如何保证这三个 key 是在归属于 Redis 集群中不同的 master 呢？
因为按照 RedLock 的理论，是需要在半数以上的 master 节点加锁成功。
阅读完源码之后，发现 RedissonRedLock 完全是 RedissonMultiLock 的子类，只是重写了 failedLocksLimit 方法，保证半数以上加锁成功即可。
所以这三个 key，是需要用户来保证分散在不同的节点上的。
在 Redisson 的 issues 也有同样的小伙伴提出这个问题，相关开发者给出的回复是用户来保证 key 分散在不同的 master 上。
更有小伙伴提出使用 5 个客户端。
那我使用 5 个单节点的客户端，然后再使用红锁，听着好像是可以的，并且 RedissonRedLock 可以这样使用。
但是那和 Redis 集群还有啥关系啊！
所以依然没有解决我的问题，还是需要用户自己来“手工定位锁”。
手工定位锁，这个…… 我考虑了下，还是不用 RedLock 吧！
当然 DarrenJiang1990 同学应该是怀着打破砂锅问到底的心情，又来了一篇 issue。
https://github.com/redisson/redisson/issues/2437
意思就是：不要关闭我的 issues，在 #2436 中说可以“手工定位锁”，但是我要怎么手工定位锁。
后来这个 issue 在 10 月才回复。
2、RedissonRedLock 被弃用
是的，没有看错，现在 RedissonRedLock 已经被启用了。
如果是看的英文文档，就会发现：
而中文文档，应该是没有及时更新。
来看看更新记录：
再找一找 issue：
Redisson 的开发者认为 Redis 的红锁也存在争议（前文介绍的那个争议），但是为了保证可用性，RLock 对象执行的每个 Redis 命令执行都通过 Redis 3.0 中引入的 WAIT 命令进行同步。
WAIT 命令会阻塞当前客户端，直到所有以前的写命令都成功的传输并被指定数量的副本确认。如果达到以毫秒为单位指定的超时，则即使尚未达到指定数量的副本，该命令也会返回。
WAIT 命令同步复制也并不能保证强一致性，不过在主节点宕机之后，只不过会尽可能的选择最佳的副本（slaves）
源码在这一部分。
看源码，同时发送了一个 WAIT 1 1000 到 Redis。
结论
Redisson RedLock 是基于联锁 MultiLock 实现的，但是使用过程中需要自己判断 key 落在哪个节点上，对使用者不是很友好。
Redisson RedLock 已经被弃用，直接使用普通的加锁即可，会基于 wait 机制将锁同步到从节点，但是也并不能保证一致性。仅仅是最大限度的保证一致性。
