首先，RedLock红色锁定是必须在分布式锁定中理解的概念。
本文首先介绍什么是RedLock。 当你对RedLock有基本知识的时候。 接下来，让我们来看看Redisson是如何实现RedLock的。
3358 www.Sina.com/http://www.Sina.com/http://www.Sina.com /
重要的事情重复三次！
什么是红岩？ RedLock，这可以从网上找到很多资料。 本文也作简要介绍，用作百叶窗。
单实例锁set resource _ name my _ random _ valuen xpx 30000在单实例Redis中只需要使用此命令。
NX )只有在key不存在时才能成功执行； PX :失效时间，进入30000后，30s后自动解锁； my_random_value :一个随机值，可以是线程号等。 主要是为了更安全地解除锁定，解除锁定时可以使用脚本Redis: 在文章开头先说明 Redisson RedLock 建议不要使用！！！解除锁定通过以下Lua脚本执行。
ifredis.call(get )，KEYS[1] )=argv[1]thenreturnredis.call )，KEYS[1] ) else return 0end为什么要设置随机值？
主要是为了防止其他客户端删除锁定。 有这样的情况：
客户端a已获得锁定，运行尚未结束，但锁定超时已自动释放； B客户端在这个时候来了，可以获得锁定，锁定成功； 此时，客户端a的执行结束，所以去解除锁定。 如果不比较随机的值，就会解除客户端b的锁定。 我当然看过Redisson的处理，但这个my_random_value结合了UUID:ThreadId的931573 de-903 e-42fd-baa7- 428 ebb 7e da 8033333
当锁遇到故障切换单实例时，确实不可靠吧？ 成功封锁后，最终Redis服务瘫痪。 这不是凉爽的事~
此时建议配置Redis主从。 即使是主仆也有偶然！
主从结构存在明显的竞争状态：
客户端a从master获取了锁定。 在master将锁定同步到slave之前，master已关闭。 slave节点提升为master节点的客户机b获得了另一个由客户机a获取相同资源的锁定。 有时候在文章开头先说明 Redisson RedLock 建议不要使用！！！程序如此巧妙。 例如，假设正好有一个节点锁定时，多个客户端同时锁定。 如果能接受这样小的概率错误，这个基于拷贝的方案就完全没有问题了。
我在用集群吗？
如果您记得前面的内容，您应该知道要锁定集群，但实际上是在CRC16的散列函数中对key进行建模，然后将结果路由到预先分配了slot的相应节点。
在文章开头先说明 Redisson RedLock 建议不要使用！！！！
RedLock的概念此时，Redis作者提出了RedLock的概念
总之，可以认为对集群的每个节点施加锁定，如果许多(N/2 1 )锁定成功，则锁定的获取被成功。
簧片锁的问题似乎通过看簧片锁解决了问题：
客户端a锁定了集群的大多数(一半以上)的客户端b也锁定了大多数； 因为这里一定会冲突，所以客户端b的锁定解除失败。 那个实际上解决了问题吗？
我建议你读两篇文章：
martinkleppmann:howtododistributedlocking
Salvatore(Redis作者):Is Redlock safe？
结果，两者各有自己的意见，没有得出结论。
因为本文主要是分析Redisson的RedLock，所以省略了额外的说明，感兴趣的伙伴可以自己阅读。
Redisson的RedLock源代码此处简要分析了Redisson的RedLock源代码，并解释了不建议使用Redisson的RedLock的原因。
使用方法
乍一看，感觉很像联锁MultiLock的使用方法呢。
实际上很相似。 RedissonRedLock完全是RedissonMultiLock的子类啊。
只需重写failedLocksLimit方法。
在多锁定中，所有锁定都必须成功。
在RedLock中，一半以上的锁定必须成功。
剩下的部分源代码与MultiLock相同，没有重复的描述。
在Redisson上Red
Lock 的问题 1、加锁 key 的问题阅读源码之前，有一个很大的疑问，我加锁 lock1、lock2、lock3，但是 RedissonRedLock 是如何保证这三个 key 是在归属于 Redis 集群中不同的 master 呢？
因为按照 RedLock 的理论，是需要在半数以上的 master 节点加锁成功。
阅读完源码之后，发现 RedissonRedLock 完全是 RedissonMultiLock 的子类，只是重写了 failedLocksLimit 方法，保证半数以上加锁成功即可。
所以这三个 key，是需要用户来保证分散在不同的节点上的。
https://github.com/redisson/redisson/issues/2436
在 Redisson 的 issues 也有同样的小伙伴提出这个问题，相关开发者给出的回复是用户来保证 key 分散在不同的 master 上。
https://github.com/redisson/redisson/issues/2127
更有小伙伴提出使用 5 个客户端。
那我使用 5 个单节点的客户端，然后再使用红锁，听着好像是可以的，并且 RedissonRedLock 可以这样使用。
但是那和 Redis 集群还有啥关系啊！
所以依然没有解决我的问题，还是需要用户自己来“手工定位锁”。
手工定位锁，这个…… 我考虑了下，还是不用 RedLock 吧！
当然 DarrenJiang1990 同学应该是怀着打破砂锅问到底的心情，又来了一篇 issue。
https://github.com/redisson/redisson/issues/2437
意思就是：不要关闭我的 issues，在 #2436 中说可以“手工定位锁”，但是我要怎么手工定位锁。
后来这个 issue 在 10 月才回复。
2、RedissonRedLock 被弃用是的，没有看错，现在 RedissonRedLock 已经被启用了。
如果是看的英文文档，就会发现：
而中文文档，应该是没有及时更新。
来看看更新记录：
再找一找 issue：
https://github.com/redisson/redisson/issues/2669
Redisson 的开发者认为 Redis 的红锁也存在争议（前文介绍的那个争议），但是为了保证可用性，RLock 对象执行的每个 Redis 命令执行都通过 Redis 3.0 中引入的 WAIT 命令进行同步。
WAIT 命令会阻塞当前客户端，直到所有以前的写命令都成功的传输并被指定数量的副本确认。如果达到以毫秒为单位指定的超时，则即使尚未达到指定数量的副本，该命令也会返回。
WAIT 命令同步复制也并不能保证强一致性，不过在主节点宕机之后，只不过会尽可能的选择最佳的副本（slaves）
源码在这一部分。
看源码，同时发送了一个 WAIT 1 1000 到 Redis。
结论Redisson RedLock 是基于联锁 MultiLock 实现的，但是使用过程中需要自己判断 key 落在哪个节点上，对使用者不是很友好。
Redisson RedLock 已经被弃用，直接使用普通的加锁即可，会基于 wait 机制将锁同步到从节点，但是也并不能保证一致性。仅仅是最大限度的保证一致性。
相关推荐 Redisson 分布式锁源码 08：MultiLock 加锁与锁释放Redisson 分布式锁源码 07：公平锁释放Redisson 分布式锁源码 06：公平锁排队加锁