redis与zookeeper分布式锁对比

主要区别

这里讲的分布式锁实现，redis是基于redisson实现，zk是基于curatorFramework实现；

1）实现的数据结构不同

redis的分布式锁是利用redis的hash数据结构，大key存储的锁名称，小key存储uuid-线程id，value存储重入次数；通过客户端往redis服务器发送lua脚本，实现redis上hash结构锁信息的更新；另外会定时复位超时时间，默认超时时间设置为30s，每10s后，若发现锁依旧被原线程持有，则复位超时时间；

zk的分布式锁是利用存储在zk上的临时有序节点，每个线程会依次在zk上创建一个临时有序节点，每个节点监听其上一个节点，没有获得锁的线程会利用synchronized的wait方法实现等待，当锁被释放时，会删除临时顺序节点，只会触发后一顺序节点去获取锁，理论上不存在竞争，只排队，非抢占，公平锁，先到先得；

2）没有获得锁的线程阻塞的方式不同

redis上是通过semaphore信号量，使没有获得锁的线程阻塞，state初始化为0，意味着所有线程都无法获得信号量，都将阻塞；

zk是通过synchronized，使没有获得锁的线程全部进入等待状态；

3）阻塞的线程被唤醒的方式不同

redis基于自带的发布订阅模式，当锁被释放时，会发布主题，从而订阅该主题的线程会唤醒semphore上阻塞的自己，继续循环获取锁；

zk是基于synchronized的wait和notify机制，以及监听watch机制，以及最小序号的节点获得锁规则；被唤醒后，继续循环直到拿到锁；

4）锁的高可用

zk具有强一致性，虽然牺牲了一定的性能，但能保证高可用，所以对追求可靠性较高的场景，可使用zk实现分布式锁；
redis具有最终一致性，特别是在redis主从架构时，只要master上锁的元数据更新了，就立即返回给客户端ok，后边会慢慢同步给slave，牺牲了可靠，对于追求性能的场景，可使用redis实现分布式锁；

具体源码分析见我的以前文章，链接如下：

用redis实现分布式锁
用zookeepe实现分布式锁