redis 分布式锁和 zk 分布式锁的对比

一、redis 分布式锁和 zk 分布式锁的对比
1、redis 分布式锁，其实需要自己不断去尝试获取锁，比较消耗性能。
2、zk 分布式锁，获取不到锁，注册个监听器即可，不需要不断主动尝试获取锁，性能开销较小。
3、如果是 redis 获取锁的那个客户端 出现 bug 挂了，那么只能等待超时时间之后才能释放锁；而 zk 的话，因为创建的是临时 znode，只要客户端挂了，znode 就没了，此时就自动释放锁。
分布式锁有 3 个重要的考量点：
1、互斥（只能有一个客户端获取锁）
2、不能死锁
3、容错（只要大部分 redis 节点创建了这把锁就可以）
二、RedLock 算法
这个场景是假设有一个 redis cluster，有 5 个 redis master 实例。然后执行如下步骤获取一把锁：
获取当前时间戳，单位是毫秒；
1、跟上面类似，轮流尝试在每个 master 节点上创建锁，过期时间较短，一般就几十毫秒；
2、尝试在大多数节点上建立一个锁，比如 5 个节点就要求是 3 个节点 n/2+1；
3、客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了；
4、要是锁建立失败了，那么就依次之前建立过的锁删除；
5、只要别人建立了一把分布式锁，你就得不断轮询去尝试获取锁。

三、redis 最普通的分布式锁
第一个最普通的实现方式，就是在 redis 里创建一个 key，这样就算加锁。
四、zk 分布式锁
zk 分布式锁，其实可以做的比较简单，就是某个节点尝试创建临时 znode，此时创建成功了就获取了这个锁；这个时候别的客户端来创建锁会失败，只能注册个监听器监听这个锁。释放锁就是删除这个 znode，一旦释放掉就会通知客户端，然后有一个等待着的客户端就可以再次重新加锁。
A、注册个监听器监听这个锁
//ZooKeeperSession
public class ZooKeeperSession{
private static CountDownLatch connectedSemaphore =new CountDownLatch(1);
private ZooKeeper zookeeper;
private CountDownLatch latch;
public ZooKeeperSession(){
try
{
this.zookeeper =new ZooKeeper(“192.168.31.187:2181,192.168.31.19:2181,192.168.31.227:2181”,50000,new ZooKeepe