redis红锁算法

分布式锁假设有N个redis 主节点，这些节点都是独立的，我们不用复本或者其他隐性协调系统，我们假设有5个节点，这是一个有依据的值，因此，我们需要在不同的计算机或虚拟机上运行5个Redis主机，确保他们失败的时候是独立的、
加锁时客户端执行以下操作
1获取当前纳秒时间
2在5个实例上依次获取锁，在所有实例中使用相同的key名字和随机值，在步骤2期间，当设置锁再每个实例时，客户端使用与总锁自动释放时间相比小的超时来获取它。
如果锁的自动释放时间是10秒，那么客户端的超时时间是 5-50 毫秒，这可防止客户端在尝试与已关闭的Redis节点通话时长时间处于阻塞状态，如果实例宕机，我们应该尽快尝试连接下一个实例。
3客户端计算获取锁所需的时间通过从当前时间减去步骤1中获得的时间戳，当且仅当客户端能够在大多数实例（至少3个）中获取锁时，获取锁所花费的总时间小于锁有效时间，则认为已获取锁。
4如果加锁成功，其有效时间被认为是初始有效时间减去在步骤3中计算的经过时间，就是锁的有效时间 == 10-获取锁花费的时间
5如果客户端由于某种原因未能获取锁，它将尝试解锁所有实例。

这个算法安全吗？

首先，我们假设客户端能够在大多数实例中获取锁所有实例都将包含一个具有相同生存时间的密钥，然而，这个key是在不用时间设置的，所以过期也会在不同的时间过期，
假设第一个key设置时间T1，最后一个key设置时间t2，我们确定第一个key的过期时间至少是MIN_VALIDITY=TTL-(T2-T1)-CLOCK_DRIFT，所以所有的key设置超时至少是这个时间
在设置大多数密钥期间，另一个客户端将无法获取锁，因为如果已经存在N/2+1个密钥，则N/2+1 set NX操作无法成功。因此，如果获取了锁，则不可能同时重新获取它

如果客户端使用接近或大于锁定最大有效时间（我们基本上用于SET的TTL）的时间锁定了大多数实例，它将认为锁定无效并将解锁实例，因此我们只需要考虑客户端能够在小于有效时间的时间内锁定大多数实例的情况。在这种情况下，对于上面已经表达的参数，对于MIN_VALIDITY，任何客户端都不能重新获取锁。因此，只有当锁定大多数实例的时间大于TTL时间时，多个客户端才能同时锁定N/2+1个实例（“时间”是步骤2的结尾），从而使锁定无效。