redission分布式锁--红锁
参考链接：①Redis分布式锁:单机Redis实现分布式锁、Redission可重入锁、Redission红锁机制(解决分布式redis单点宕机故障转移存在的遗留问题)
问题
最近看一些redis分布式锁的资料，大体思路都是一致，而且基本上都是用的Redission。
这个本身也没啥问题，但是奇怪的是，在介绍分布式锁的缺点时，总是千篇一律的介绍了一种异常情况，是分布式锁redission无法处理的。具体发生的过程介绍如下：
1）redis的部署方式为一主多从
2）如果客户端1给redis主节点加了分布式锁，但是redis主节点在异步复制给从节点之前就挂了，导致分布式锁丢失
3）某个从节点自动成为新的主节点后，因为同步锁丢失的原因，并不知道客户端1已经加锁，这时客户端2也来了加锁行为，这时客户端2自然加锁成功！！！
问题的关键是，客户端1没有主动释放锁，也没有因为过期而释放锁，这时客户端2就能得到锁，这不是很大的问题吗？我们的分布式锁，在这种情况下，不是失去意义了吗？？？
完善办法
我刚开始也觉得，基于这种情况，说的挺有道理，实在是无解，毕竟数据丢了，没有办法。
但是（注意我要开始ZB了），我觉得肯定会有其他解决方案，或者更进一步完善的方案，对不对？
果然，就发现了另一个神奇的东西：红锁（RedLock），redission里对应RedissonRedLock
红锁的关键思想：
1）加锁时，尝试给每个redis节点都加锁
2）必须有超过一半的redis加锁成功，才算本次加锁成功（加锁成功含义：成功获取到锁，且耗时时间小于锁失效时间）
比如有1个主redis节点、4个从节点，那么总共有5个节点，红锁加锁时，会同时往5个节点都加锁，并且至少3个节点加锁成功，才算最终加锁成功。
如果加了红锁机制后，主从情况下，分布式锁刚加完，主节点挂掉，那么新的从节点大概率会持有分布式锁。
为什么会是大概率？因为可能当时红锁加锁也成功了，但是其实5节点中，有一个从节点挂掉了，所以改从节点没有分布式锁，但是之后又被实施人员启动了，这种时候，如果主节点挂掉，而刚启动起来的从节点又刚好被作为新的主节点，那么还有会有问题。
