基于zookeeper实现分布式锁的底层原理

注：关于什么是分布式锁及其应用场景这里不赘述，需要了解请自行百度！

一 zookeeper分布式锁原理：

原理图基于curator(zookeeper客户端框架)，具体代码实现看下官网API(很简单)，此图解释了以下问题：

1. 多线程间如何获取锁资源？
2. 一个线程内重复加锁如何处理？
3. 争抢锁资源时如何保证性能？
4. 节点挂机是否会造成死锁？
5. 如何解决高可用？
   

二 redis分布式锁RedLock算法简单介绍(java API基于Redisson)：

1）获取当前时间戳，单位是毫秒；
2）尝试在大多数节点上建立一个锁，必须在大多数redis节点上都成功创建锁，才能算这个整体的RedLock加锁成功(保证高可用)，过期时间较短，一般就几十毫秒，在每个节点上创建锁的过程中，需要加一个超时时间，一般来说比如几十毫秒如果没有获取到锁就超时了，标识为获取锁失败；
4）客户端计算建立好锁的时间，如果建立锁的时间小于超时时间，就算建立成功了；
5）要是锁建立失败了，那么就依次删除已经创建的锁；
6）只要别人创建了一把分布式锁，你就得不断轮询去尝试获取锁。

三 基于zookeeper和redis实现分布式锁的比较和选型：

1. 基于组件架构而言：
   redis从一开始设计架构的时候就不是作为分布式协调组件来设计的，而zookeeper的设计初衷就是作为分布式系统的基础技术；
2. 基于性能和健壮性而言:
   redisson锁支持的很好，但是比较复杂，RedLock需要轮询获取锁需要考虑性能消耗，而curator是通过注册监听器由线程主动告知，可以用zk就不建议使用redis，zk锁模型很健壮，而且有良好的curator客户端对各种类型的分布式锁的支持。