Redisson实现分布式锁原理
如图所示啊，石杉大佬画的redisson分布式锁原理。
大概总结下，保证我们的key落到一个集群里，并且加锁操作是基于lua脚本的原子性操作，对于锁延迟由watch dog控制。
具体可以看 https://www.cnblogs.com/AnXinliang/p/10019389.html
如果你对某个redis master实例，写入了myLock这种锁key的value，此时会异步复制给对应的master slave实例。但是这个过程中一旦发生redis master宕机，主备切换，redis slave变为了redis master。
接着就会导致，客户端2来尝试加锁的时候，在新的redis master上完成了加锁，而客户端1也以为自己成功加了锁。
此时就会 导致多个客户端对一个分布式锁完成了加锁。
这时系统在业务语义上一定会出现问题，导致各种脏数据的产生。
所以这个就是redis cluster，或者是redis master-slave架构的主从异步复制导致的redis分布式锁的最大缺陷：在redis master实例宕机的时候，可能导致多个客户端同时完成加锁。
如果主动结构redis架构模式下，我们想保证完全一致，必须重写加锁的逻辑了， 保证必须mater和slave同时加锁成功，我们整个加锁才是成功的 。
上面的2是对于单个主从结构我们可以这样干，如果假设我们有多个相对独立的master，无slave呢？我们在其中一个master上加了🔐，然后它挂了岂不是我们的数据会在剩下的结点会重新加锁成功？
redis引入了 红锁 的概念：用Redis中的多个master实例，来获取锁，只有 大多数 实例获取到了锁，才算是获取成功 。
具体的红锁算法分为以下五步：
以上步骤来自redis 分布式锁的解释,如下
”相同的key和随机值（随机值用于唯一关系客户端和key）在N个节点上请求锁“
这里的随机数是什么？
这对于 避免删除由另一个客户端创建的锁 很重要。例如，客户端可能会获取锁，执行某些操作时被阻塞的时间超过锁的有效时间（密钥将过期的时间），然后移除已被其他客户端获取的锁。使用 just DEL 是不安全的，因为客户端可能会删除另一个客户端的锁。使用上面的脚本，每个锁都用一个随机字符串“签名”，所以只有当它仍然是客户端试图移除它时设置的锁才会被移除。
这个随机字符串应该是什么？我们假设它是 20 个字节 /dev/urandom ，但您可以找到更便宜的方法使其对您的任务足够独特。例如，一个安全的选择是用 RC4 播种 /dev/urandom ，并从中生成一个伪随机流。一个更简单的解决方案是使用具有微秒精度的 UNIX 时间戳，将 时间戳与客户端 ID 连接起来。它并不安全，但对于大多数环境来说可能就足够了。
假设一共有5个Redis节点：A, B, C, D, E。设想发生了如下的事件序列：
为了应对这一问题，提出了 延迟重启 (delayed restarts)的概念。
就是,一个节点崩溃后，先不立即重启它，而是等待一段时间再重启，这段时间应该大于锁的有效时间(lock validity time)。
这样的话，这个节点在重启前所参与的锁都会过期，它在重启后就不会对现有的锁造成影响。
客户端1在获得锁之后发生了很长时间的GC pause，在此期间，它获得的锁过期了，而客户端2获得了锁。
当客户端1从GC pause中恢复过来的时候，它不知道自己持有的锁已经过期了，它依然向共享资源（ 比如 一个存储服务）发起了写数据请求，
而这时锁实际上被客户端2持有，因此两个客户端的写请求就有可能冲突（锁的互斥作用失效了）。
如何解决这个问题呢?引入了 fencing token 的概念：
首先：RedLock根据随机字符串来作为单次锁服务的token，这就意味着对于资源而言，无法根据锁token来区分client持有的锁所获取的先后顺序。
fencing token可以理解成采用全局递增的序列替代随机字符串,即 有序token ，作为锁token来使用
流程：
假设有5个Redis节点A, B, C, D, E。
这个问题用Redis实现分布式锁暂时无解。而生产环境这种情况是存在的。
时钟跳跃是可以避免的，取决于基础设施和运维； 时钟跳跃是可以避免的，取决于基础设施和运维；
redis是保持的AP而非CP，如果要追求强一致性可以使用zookeeper分布式锁，但是zookeeper也不是完全没问题，在出现网络颜值，客户端与服务端失联情况的时候也依然可能会出现分布式的问题。
