Redlock
什么是 RedLock
Redis 官方提出了一种权威的基于 Redis 实现分布式锁的方式名叫Redlock，在分布式系统里需要锁一些资源的时候就可以用到分布式锁。这种方式比原先的单节点的方法更安全。它可以保证以下特性：
-
安全特性：互斥访问，即永远只有一个 client 能拿到锁
-
避免死锁：最终 client 都可能拿到锁，不会出现死锁的情况，即使原本锁住某资源的 client crash 了或者出现了网络分区
-
容错性：只要大部分 Redis 节点存活就可以正常提供服务
Redlock 算法
我们假设有 5 个 master 节点，分布在不同的机房，保证其可用性。为了获得锁，client 会进行如下操作：
-
以微秒为单位得到当前的时间，
-
尝试顺序地在 5 个实例上申请锁，使用相同的 key 和 random value，这里一个 client 需要合理设置与 master 节点沟通的 timeout 大小，避免长时间和一个 fail 了的节点浪费时间
-
当 client 在大于等于 3 个 master 上成功申请到锁的时候，它会计算申请锁消耗了多少时间，这部分消耗的时间采用获得锁的当下时间减去第一步获得的时间戳得到，如果锁的持续时长（lock validity time）比流逝的时间多的话，那么锁就真正获取到了。
-
如果锁申请到了，那么锁真正的 lock validity time 应该是 origin（lock validity time） - 申请锁期间流逝的时间
-
如果 client 申请锁失败了，那么它就会在少部分申请成功锁的 master 节点上执行释放锁的操作，重置状态
如果一个 client 申请锁失败了，那么它需要稍等一会在重试。避免多个 client 同时申请锁的情况，并且 client 申请锁失败了它需要尽快在它曾经申请到锁的 master 上执行 unlock 操作，便于其他 client 获得这把锁，避免这些锁过期造成的时间浪费。
为什么尽量不用
Redlock 实在不是一个好的选择，对于需求性能的分布式锁应用它太重了且成本高；对于需求正确性的应用来说它不够安全。如果你的应用只需要高性能的分布式锁不要求多高的正确性，那么单节点 Redis 够了；如果你的应用想要保住正确性，那么不建议 Redlock，建议使用一个合适的一致性协调系统，例如 Zookeeper，且保证存在 fencing token。