超级详细，结合分布式理论讲解分布式锁各种实现（redis，zookeeper，mysql）

分布式理论

1、分布式编程是解决您可以使用多台计算机在单台计算机上解决的同一问题的艺术- 通常，因为问题不再适合单台计算机

2、分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器，处理
更多的数据。

3、分布式系统的核心定理CAP，该定理指出了这三个性质：

（1） 一致性：所有节点同时看到相同的数据。

（2） 可用性：节点故障不会阻止幸存者继续操作。

（3） 分区容错性：尽管由于网络和/或节点故障导致消息丢失， 系统仍继续运行

4，CAP定理的运用

只有两个可以同时满足。可以将其绘制为一个漂亮的图表，从三个属性中选择两个属性为我们提供了三种类型的系统，它们对应于不同的交叉点，如图：
该定理指出中间部分（具有所有三个属性）是不可实现的。然后我们得到三种不同的系统类型：

（1） CA（一致性+可用性）。示例包括完全严格的仲裁协议，例如两阶段提交。

（2） CP（一致性+分区容错性）。示例包括多数仲裁协议，其中少数分区不可用，例如Paxos。

（3） AP（可用性+分区容错性）。示例包括使用冲突解决的协议，例如Dynamo。

5，设计技巧：分区和复制

数据集在多个节点之间分布的方式非常重要。为了进行任何计算，我们需要定位数据，然后对其采取行动。

有两种基本技术可以应用于数据集。它可以拆分到多个节点（分区）以允许更多的并行处理。它也可以被复制或缓存在不同的节点上，以减少客户端和服务器之间的距离和更大的容错（复制）。

• 分区

  分区是将数据集划分为更小的不同的独立集；这用于减少数据集增长的影响，因为每个分区都是数据的一个子集。
  分区通过限制要检查的数据量和在同一分区中定位相关数据来提高性能
  分区通过允许分区独立失败来提高可用性，增加在牺牲可用性之前需要失败的节点数量

• 复制

  复制是在多台机器上复制相同的数据；这允许更多的服务器参与计算。

什么是锁？

在并发编程中，经常会遇到多个线程访问同一个共享资源，这时候我们要保证数据的一致性，那么就要用到了锁的概念，给资源加上锁，拿到锁所有权的人才能够进行操作共享资源，没有拿到锁的线程需要等待，等锁的所有权放开。

Java中实现锁的工具类有: synchronized和JDK以后才引用Lock接口锁. 如：ReentrantLock（可重入锁），ReadWriteLock （读写锁） ReentrantReadWriteLock （可以选择获取什么锁）

在单机多线程的java程序中，我们可以使用堆内存中的变量作为标志，因为多线程是共享堆内存的，堆内存中的变量对于各个线程都是可见的。
但是在分布式系统的java程序中Java提供的锁就无法解决多线程问
题了。

分布式锁概念

与分布式锁相对应的是「单机锁」，我们在写多线程程序时，避免同时操作一个共享变量产生数据问题，通常会使用一把锁来「互斥」，以保证共享变量的正确性，其使用范围是在「同一个进程」中。
如果换做是多个进程，需要同时操作一个共享资源，如何互斥呢？例如，现在的业务应用通常都是分布式架构，为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。
分布式锁的引入：一个应用会部署多个进程，那这多个进程如果需要修改MySQL 中的同一行记录时，为了避免操作乱序
导致数据错误，此时，我们就需要引入「分布式锁」来解决这个问题了。
想要实现分布式锁，必须借助一个外部系统，所有进程都去这个系统上申请「加锁」，而这个外部系统，必须要实现「互斥」的能力，即两个请求同时进来，只会给一个进程返回成功，另一个返回失败（或等待）。
这个外部系统，可以是MySQL，也可以是Redis 或Zookeeper。但为了追求更好的性能，我们通常会选择使用Redis或Zookeeper 来做。

分布式锁的特点

• 互斥性：保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。
• 可重入性：这把锁要是一把可重入锁（避免死锁），类似于ReentrantLock，同一服务节点的相同线程， 允许重复多次加锁；
• 阻塞性：支持阻塞和非阻塞: 和ReentrantLock 一样支持lock 和trylock 以及tryLock(long timeOut)。
• 高可用：有高可用的获取锁和释放锁功能
• 锁超时：支持锁超时，及时释放，防止锁死。
• 公平锁与非公平锁：公平锁是指按照请求加锁的顺序获得锁，非公平锁请求加锁是无序的。

分布式的实现方式

• 数据库
  创建一张表, 通过对此表的insert/delete 达到获取, 释放锁的目的; 需要解决DB单点故障, 释放锁失败, 堵塞锁等情况;
  优点:借助DB, 容易理解
  缺点:性能开销大, 有些笨重, 可能导致系统越来越复杂
• Redis
  集群redis中通过setnx与expire, 或者setnx与getset设置锁的过期时间, 实现分布式锁;
  优点: 有效解决单点问题, 性能高，实现起来较为方便;
  缺点:setnx与expire无法确保事务, 一个客户端堵塞很久导致expire自动执行,
  Redlock：是redis的作者设计的分布式锁方案
  优点: •可用性高，大多数节点正常即可。 •单Redis 节点的分布式锁在
  failover 时锁失效问题不复存在。
  缺点: 设计比较复杂,个人实现比较麻烦,最好借用已经实现了的库
  (Redission…)
• Zookeeper
  优点：有效的解决单点问题，不可重入问题，非阻塞问题以及锁无法释放的问题
  实现较为简单
  缺点：性能上不如使用缓存实现的分布式锁，因为每次在创建锁和释放锁的过程中，都要动态创建、销毁临时节点来实现锁功能需要对Zookeeper的原理有所了解。

4，Etcd

数据库

1，创建一张表

CREATE TABLE `dl_lock` (
`id` int NOT NULL AUTO_INCREMENT COMMENT '主键',
`lock_name` varchar(64) CHARACTER SET utf8 NOT NULL DEFAULT '' COMMENT '锁名',
`desc` varchar(1024) CHARACTER SET utf8 NOT NULL DEFAULT '备注信息' COMMENT '描述信息',
`update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间（当前时间）',
PRIMARY KEY (`id`) USING BTREE,
UNIQUE INDEX `uidx_method_name`(`lock_name`) USING BTREE
) ENGINE = InnoDB AUTO_INCREMENT = 1 COMMENT = '锁定中的方法' ROW_FORMAT =
Dynamic;

2，表结构

3，唯一索引（uidx_method_name）

4，代码实现

/**
* 非阻塞获取锁
*
* @param lockName  锁的名称
* @param desc	描述
* @return 成功:1
*/
public boolean  lock(String lockName, String desc) {
    
     try {
    
    
//加锁，成功则返回true，失败则证明已经加锁或发送其他异
常
int  result = insert(lockName, desc); if (result == 1) {
    
    
return true;
}
} catch (DuplicateKeyException  e) {
    
    
log.info("锁已经被其他线程获取,获取锁失败");
} catch (Exception e) {
    
    
log.info("sql  exception,获取锁失败");
}
return false;
}

/**
* 阻塞获取锁
*
* @param lockName  锁的名称
* @param desc	描述
* @return 成功:1
*/
public void blockLock(String lockName, String desc) {
    
     

while (true) {
    
    
//获取锁
if (lock(lockName, desc)) {
    
     
   return;
}
//阻塞当前线程3秒LockSupport.parkNanos(3 * 1000 * 1000);
}
}

/**
* 删除记录
*
* @param  lockName  锁名，唯一
* @return
*/
public int  delete(String lockName) {
    
    
Map<String, Object> param  = new HashMap<>(); 
param.put("lockName", lockName);
String sql  = "delete from dl_lock  where lock_name
= :lockName";
return namedParameterJdbcTemplate.update(sql, param);
}

/**
* 锁释放，删除锁记录
*
* @param  lockName  锁名，唯一
* @return
*/
public int  release(String lockName) {
    
    
 return delete(lockName);
}

5，应用

public void apply() {
    
    
String lockName  = "test02_lock_name";
//获取锁，如果没有获取到锁，会阻塞直到获取到锁dlLockTemplate.blockLock(lockName, "测试锁02"); 
try {
    
    
log.info(Thread.currentThread().getName()+"业务开始执行。。。。。。。");
//业务实现

TimeUnit.SECONDS.sleep(3);
} catch (Exception e) {
    
    
//业务异常
} finally {
    
    
//业务执行完毕后，释放锁
dlLockTemplate.release(lockName);
log.info(Thread.currentThread().getName()+"业务执行结束。。。。。。。");
}
}

6，是否满足分布式锁的所有要求？
（1） 互斥性：保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。
答： 满足
（2） 可重入性：这把锁要是一把可重入锁（避免死锁），类似于ReentrantLock，同一服务节点的相同线程，允许重复多次加锁；
答：可以实现，利用锁的节点信息判断是否是重入锁。
（3） 阻塞性：支持阻塞和非阻塞: 和ReentrantLock 一样支持lock 和trylock 以及tryLock(long timeOut)。答：支持
（4） 高可用：有高可用的获取锁和释放锁功能答：高可用
（5） 锁超时：支持锁超时，及时释放，防止锁死。
答：支持锁超时释放，但需要通过定时任务去查询锁的失败日志去释放，不够及时。
（6） 公平锁与非公平锁：公平锁是指按照请求加锁的顺序获得锁，非公平锁请求加锁是无序的。答：可以实现，比较复杂，通过表记录来实现公平锁的顺序性。

基于数据库锁做分布式锁

在查询语句后面增加for update，数据库会在查询过程中给数据库表增加排他锁 (注意：InnoDB 引擎在加锁的时候，只有通过索引进行检索的时候才会使用行级锁，否则会使用表级锁。这里我们希望使用行级锁，就要给要执行的方法字段名添加索引，值得注 意的是，这个索引一定要创建成唯一索引，否则会出现多个重载方法之间无法同时被访问的问题。重载方法的话建议把参数类型也 加上。)。当某条记录被加上排他锁之后，其他线程无法再在该行记录上增加排他锁。

基于redis的setnx实现

命令：setnx key value ex 10 nx
1，超时获取锁方法（加锁，自旋，超时后会获取失败）

public boolean tryLock(String lockKey, String valueForRequestId, long timeout) {
    
    

long start = System.currentTimeMillis();
boolean locked = false; while (true) {
    
    
//超时，锁获取失败
if (System.currentTimeMillis() - start > timeout) {
    
     break;
} //加锁，成功返回true，失败返回false
Boolean result = redisTemplate.opsForValue().setIfAbsent(lockKey, valueForRequestId,  timeout, TimeUnit.SECONDS);
 if (Boolean.TRUE.equals(result)) {
    
    
locked = true; break;
} else {
    
    
//500毫秒后重试
LockSupport.parkNanos(TimeUnit.NANOSECONDS.convert(500, TimeUnit.MILLISECONDS));
}
}
return locked;
}

2，两种解锁方法

/**
*	通过lua脚本锁
*
*	@param lockKey 锁key
*	@return 释放结果
*/
public boolean releaseLock(String lockKey, String valueForRequestId) {
    
     

if (lockKey == null || valueForRequestId == null)
return false;
DefaultRedisScript<Long> redisScript = new DefaultRedisScript();
//用于解锁的lua脚本位置
redisScript.setLocation(new ClassPathResource("unlock.lua")); redisScript.setResultType(Long.class);
//没有指定序列化方式，默认使用上面配置的
Object result = redisTemplate.execute(redisScript, Arrays.asList(lockKey), valueForRequestId);
return result.equals(Long.valueOf(1));
}

/**
* 非原子解锁，可能解别人锁，不安全
*/
public boolean unlock(String lockKey, String valueForRequestId) {
    
     if (lockKey == null || valueForRequestId == null)
return false;
boolean releaseLock = false;
String requestId = redisTemplate.opsForValue().get(lockKey); if (valueForRequestId.equals(requestId)) {
    
    
releaseLock = redisTemplate.delete(valueForRequestId);
}
return releaseLock;
}

Lua脚本

if redis.call('get',KEYS[1]) == ARGV[1] then return redis.call('del',KEYS[1])
else
return 0
end

需要注意的问题

（1） 设置过期时间

（2） 保证加锁和设置过期时间的原子性

（3） Value值使用特定值(进程ID,IP地址,docker ID之类)进行区分,防止误删

（4） 尽可能的使用lua脚本
存在的问题
（1）单体性能堪忧，集群，主从等无法防止单节点故障造成锁丢失

是否满足分布式锁的所有问题？

（1） 互斥性：保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。
答：不满足， 极端情况，如果客户A持有锁，但客户A阻塞住并且锁过期了，这时客户B进来之后同样会成功持有锁， 此时客户A和客户B都拥有了这把锁，无法满足互斥性。
解决方案：在客户A持有锁的时候，如果客户A没有执行完业务或者阻塞情况下，需要给客户A持有的锁进行续命， 也就是常说的锁续命

（2） 可重入性：这把锁要是一把可重入锁（避免死锁），类似于ReentrantLock，同一服务节点的相同线程，允许重复多次加锁；
答：可以实现，利用锁的节点信息判断是否是重入锁。
（3） 阻塞性：支持阻塞和非阻塞: 和ReentrantLock 一样支持lock 和trylock 以及tryLock(long timeOut)。答：支持
（4） 高可用：有高可用的获取锁和释放锁功能答：高可用
（5） 锁超时：支持锁超时，及时释放，防止锁死。答：支持锁超时释放，可以设置过期时间。
（6） 公平锁与非公平锁：公平锁是指按照请求加锁的顺序获得锁，非公平锁请求加锁是无序的。答：可以实现，比较复杂，通过记录来实现公平锁的顺序性。

通过Redisson实现分布式锁

Redisson是架设在Redis基础上的一个Java驻内存数据网格（In-Memory Data Grid）。充分的利用了Redis键值数据库提供的一系列优势，基于Java 实用工具包中常用接口，为使用者提供了一系列具有分布式特性的常用工具类。使得原本作为协调单机多线程并发程序的工具包获得了协调分布式多机多线程并发系统的能力，大大降低了设计和研发大规模分布式系统的难度。同时结合各富特色的分布式服务，更进一步简化了分布式环境中程序相互之间的协作。
Redisson提供了主从，集群，单实例，哨兵等配置。
并且Redisson内部代码实现了很多细节，比如内部的看门狗。
而且也实现了多种锁。

通过Redisson实现分布式锁

RedLock的出现

基于setnx实现分布式锁可能会出现丢锁的现象

1，客户A，拿到了锁lockKey
2, master要把锁数据lockKey同步给slave，这时master宕机了
3，主从切换，slave晋升为master
4，客户B需要获取锁，到master获取锁，同样拿到了锁这时候，同一把锁，两个人同时拿到。

• 无论redis是主从+哨兵还是集群都存在这样的风险。因为这个问题，
  Redis 之父antirez 提出了redisson的RedLock（红锁）算法

• RedLock的优点

（1） 可用性高，大多数节点正常即可。

（2） 单Redis 节点的分布式锁在failover 时锁失效问题不复存在
RedLock的缺点

（3）设计比较复杂,个人实现比较麻烦,最好借用已经实现了的库
(Redission…)

• RedLock算法

Redlock为了解决CAP的cp,数据一致性，采用有n个redis节点，n为奇数（官方推荐5个实例），来保证他们大多数情况下都不会同时宕机，这些节点是完全独立的，因此我们不使用复制或任何其他隐式协调系统。我们已经描述了如何在单个实例中安全地获取和释放锁。我们理所当然地认为算法会在单个实例中使用这种方法来获取和释放锁。在我们的示例中，我们设置了N=5，这是一个合理的值，因此我们需要在不同的计算机或虚拟机上运行 5 个Redis 主节点，以确保它们以几乎独立的方式失败。
为了获取锁，客户端执行以下操作：
（1），它以毫秒为单位获取当前时间。
（2），它尝试顺序获取所有N 个实例中的锁，在所有实例中使用相同的键名和随机值。在第 2 步中，当在每个实例中设置锁时，客户端使用一个比总锁自动释放时间更小的超时来获取它。例如，如果自动释放时间为 10 秒，则超时可能在~ 5-50 毫秒范围内。这可以防止客户端长时间处于阻塞状态，试图与已关闭的Redis 节点通信：如果实例不可用，我们应该尽快尝试与下一个实例通信。
（3），客户端通过从当前时间中减去步骤 1 中获得的时间戳来计算获取锁所用的时间。 当且仅当客户端能够在大多数实例（至少 3 个）中获取锁，并且获取锁所用的总时间小于锁有效时间，则认为该锁已获取。
（4），如果获得了锁，则其有效时间被视为初始有效时间减去经过的时间，如步骤 3 中计算的那样。
（5），如果客户端由于某种原因获取锁失败（或者它无法锁定N/2+1 个实例或有效时间为负），它将尝试解锁所有实例（即使是它认为没有成功获取锁的实例）。

• RedLock的方案

Redlock 的方案基于 2 个前提：
（1） 不再需要部署从库和哨兵实例，只部署主库
（2） 但主库要部署多个，官方推荐至少 5 个实例

注意：不是部署Redis Cluster，就是部署 5 个简单的Redis 实例。
Redisson 实现方式（红锁RedLock）
github Redisson：

https://github.com/redisson/redisson
https://github.com/redisson/redisson/wiki/2.-Configuration
RedLock：
https://redis.io/topics/distlock

Redisson

1，Redission使用

（1）添加maven配置

<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>3.16.1</version>
</dependency>

Redisson客户端配置

可以有集群，主从，哨兵，单节点等不同配置的客户端。但他们会丢失锁。
红锁的配置算法则不会出现锁丢失：

配置三个客户端，redissonSingleClient1，redissonSingleClient2，
redissonSingleClient3，像下面这一样，注入三个Bean，以client1为例子。

/**
* redisson客户端单机模式1
*/
@Bean("client1")
public RedissonClient redissonSingleClient1() {
    
     
Config config1 = new Config();
 config1.useSingleServer()
//可以用"rediss://"来启用SSL连接
.setAddress("redis://192.168.145.132:6379");//...other config add return Redisson.create(config1);
}

通过三个客户端Rlock，构造一把红锁RedissonRedLock。

private RedissonRedLock redLock; @BeforeEach
public void init() {
    
    
String lockKey = "lock_key";
RLock lock1 = redissonClient1.getLock(lockKey); 
RLock lock2 = redissonClient2.getLock(lockKey); 
RLock lock3 = redissonClient3.getLock(lockKey); 
redLock = new RedissonRedLock(lock1, lock2, lock3);
}

实现分布式锁的一个非常重要的点就是set的value要具有唯一性， redisson的value是怎样保证value的唯一性呢？答案是UUID+threadId。源码在Redisson.java和RedissonLock.java中：

锁的核心代码，根据lua脚步实现

应用

public void apply() {
    
     try {
    
    
//尝试等待10秒，加锁3秒
boolean lock = redLock.tryLock(10, 3, TimeUnit.SECONDS); log.info(Thread.currentThread().getName() +"redLock:{}",lock); 
if (lock) {
    
    
log.info(Thread.currentThread().getName() + " 业务执行开始。。。。。。。。。");
//业务实现TimeUnit.SECONDS.sleep(3);
}
} catch (Exception e) {
    
    
} finally {
    
     redLock.unlock();
log.info(Thread.currentThread().getName() + "业务执行结束。。。。。。。。。");
}
}

分布式专家Martin 对于Redlock 的质疑？

• 分布式锁的目的是什么？
  Martin认为，RedLock仍然没有解决锁失效的问题，认为这种算法，就像是给患者服用了重复剂量的药物
  一样。

• 锁在分布式系统中会遇到的问题

• 
  分布式系统的NPC问题导致出现的问题

• 假设时钟正确的是不合理的
  Redlock 必须「强依赖」多个节点的时钟是保持同步的，一旦有节点时钟发生错误，那这个算法模型就失效了。Redlock 的算法是建立在「同步模型」基础上的，但同步模型的假设，在分布式系统中是有问题的。

• 提出fecing token 的方案，保证正确性

这个模型流程如下：
1，客户端在获取锁时，锁服务可以提供一个「递增」的token
2，客户端拿着这个token 去操作共享资源
3，共享资源可以根据token 拒绝「后来者」的请求

Martin 的结论：

1、Redlock 不伦不类：它对于效率来讲，Redlock 比较重，没必要这么做，而对于正确性来说，Redlock 是不够安全的。
2、时钟假设不合理：该算法对系统时钟做出了危险的假设（假设多个节点机器时钟都是一致的），如果
不满足这些假设，锁就会失效。
3、无法保证正确性：Redlock 不能提供类似fencing token 的方案，所以解决不了正确性的问题。为了正确性，请使用有「共识系统」的软件，例如Zookeeper。

Redis 作者Antirez 的反驳 ：

• 解释时钟问题
  Redis 作者表示，Redlock 并不需要完全一致的时钟，只需要大体一致就可以了，允许有「误差」。
• 解释网络延迟、GC 问题
  在RedLock算法的第三步是可以避免的，如果是获取锁操作共享资源的过程出现问题，那这不止是RedLock的问题，任何其他锁服务，例如zookeeper也有问题
• 质疑fencing token 机制
  1， 这个方案必须要求要操作的「共享资源服务器」有拒绝「旧token」的能力。
  2，既然资源服务器都有了「互斥」能力，那还要分布式锁干什么？
  3， Redlock 已经提供了随机值（ UUID），利用这个随机值，也可以达到与fecing token 同样的效果

Zookeeper实现分布式锁

ZooKeeper 是一个分布式的，开放源码的分布式应用程序协调服务，是 Google 的Chubby 一个开源的实现。它提供了简单原始的功能，分布式应用可以基于它实现更高级的服务，比 如分布式同步，配置管理，集群管理，命名管理，队列管理。它被设计为易于编程，使用文件系统目录树作为数据模型。服务端跑在 java 上，提供java 和C 的客户端API。
官网地址：http://ZooKeeper.apache.org/
官网API 地址：http://ZooKeeper.apache.org/doc/r3.4.10/api/index.html

ZooKeeper 作为一个集群提供数据一致的协调服务，自然，最好的方式就是在整个集群中的各服务节点进行数据的复制和同步数据复制的好处：

1、容错：一个节点出错，不至于让整个集群无法提供服务。
2、扩展性：通过增加服务器节点能提高 ZooKeeper 系统的负载能力，把负载分布到多个节点上。
3、高性能：客户端可访问本地 ZooKeeper 节点或者访问就近的节点，依次提高用户的访问速度。
特点：
1、 最终一致性：client 不论连接到哪个Server，展示给它都是同一个视图，这是 ZooKeeper 最重要的性能。
2、 可靠性：具有简单、健壮、良好的性能，如果消息 m 被到一台服务器接受，那么它将被所有的服务器接受。
3、 实时性：ZooKeeper 保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者 服务器失效的信息。但由于网络延时等原因，
ZooKeeper 不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用 sync()接口。
4、 等待无关（wait-free）：慢的或者失效的 client 不得干预快速的client 的请求，使得每个client 都能有效的等待
5、 原子性：更新只能成功或者失败，没有中间状态。
6、 顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息 a 在消息b 前发布，则在所有Server 上消息a 都将在消息
b 前被发布；偏序是指如果一个消息 b 在消息a 后被同一个发送者发布，a 必将排在b 前面。

Zookeeper集群的选举策略

配置多个实例共同构成一个集群对外提供服务以达到水平扩展的目的，每个服务器上的数据是相同的，每一个服务器均可以对外提供读和写的服务。
Zookeeper角色分为Leader和Follower，Leader通过选举产生，Leader产生后，其余节点自动为Follower。选举机制为过半机制。
Zookeeper的四种角色：

Zookeeper集群的选举策略(Zab协议)

选举过程中，zookeeper对客户端是停止访问的，所以只满足CAP中的CP,满足一致性。

Zookeeper文件系统

Zookeeper提供了一个类似文件系统的数据结构。其实zookeeper本身就是一个文件系统+通知机制的系统。

每个子目录项如NameService 都被称作为znode，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。

有四种类型的znode：

1、PERSISTENT-持久化目录节点
客户端与zookeeper断开连接后，该节点依旧存在

2、 PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号

3、EPHEMERAL-临时目录节点
客户端与zookeeper断开连接后，该节点被删除

4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

根据Zookeeper的有序节点（编号），临时节点（自动删除）和事件监听特质，可以很方便的实现分布式锁。

事件监听：当节点数据或结构变化时，Zookeeper会通知客户端，当前Zookeeper有以下四种事件：
1，节点创建；
2，节点删除；
3，节点数据修改；
4，子节点变更。

ZooKeeper 实现分布式锁的主要流程：

1，当第一个线程进来时会去父节点上创建一个临时的顺序节点。

2，第二个线程进来发现锁已经被持有了，就会为当前持有锁的节点注册一个watcher 监听器。

3，第三个线程进来发现锁已经被持有了，因为是顺序节点的缘故，就会为上一个节点去创建一个watcher
监听器。

4，当第一个线程释放锁后，删除节点，由它的下一个节点去占有锁。

Curator框架实现分布式锁

Curator是Netflix公司开源的一套zookeeper客户端框架，解决了很多Zookeeper客户端非常底层的细节开发工作，包括
连接重连、反复注册Watcher和NodeExistsException异常等等。Patrixck Hunt（Zookeeper）以一句“Guava is to Java that Curator to Zookeeper”给Curator予高度评价。
1，引入pom

<dependency>
<groupId>org.apache.zookeeper</groupId>
<artifactId>zookeeper</artifactId>
<version>3.7.0</version>
</dependency>

<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-recipes</artifactId>
<version>2.12.0</version>
</dependency>

<dependency>
<groupId>org.apache.curator</groupId>
<artifactId>curator-framework</artifactId>
<version>2.12.0</version>
</dependency>

2，创建客户端连接

/**
*	zkAddr zk地址 ip:port,ip:port,ip:port
*	timeOut 连接超时ms
*	namespace 所有的操作都是在 /namespace 下的节点操作
*	acl Access Control List（访问控制列表）。Znode被创建时带有一个ACL列表<br>
*/
private String zkAddr="192.168.145.132:2181";
 private int timeOut=10000;
private String namespace="zk_lock"; @Bean
public CuratorFramework curatorFramework() throws Exception {
    
     RetryPolicy retryPolicy = new ExponentialBackoffRetry(1000, 3); CuratorFrameworkFactory.Builder builder = CuratorFrameworkFactory
.builder()
.connectString(this.zkAddr)
.namespace(StringUtils.isEmpty(namespace) ? “” : namespace)
.connectionTimeoutMs(this.timeOut)
.retryPolicy(retryPolicy); 
CuratorFramework client= builder.build(); 
client.start(); //启动客户端
client.blockUntilConnected(5, TimeUnit.SECONDS); 
return client;
}

分布式锁对象InterProcessMutex：
（1） Client：Zookeeper客户端
（2） path: 锁空间的根节点路径

获取锁方法，this.internalLock（-1，null）方法的参数会永久阻塞：

释放锁：

1，在zk_lock下创建路径为test_lock的锁，结果如右图所示

public void apply() throws Exception {
    
    
//创建分布式锁，根节点为test_lock 
InterProcessLock test =zookeeperLock.getInterProcessLock("/test_lock");
//获取锁
test.acquire();
//业务实现try {
    
    
TimeUnit.SECONDS.sleep(100);
} catch (Exception e) {
    
    
}finally {
    
    
//释放锁test.release();
}
}

1，启动三个线程去调用观察

@Test
public void test01() throws Exception {
    
     
for (int i = 0; i < 3; i++) {
    
    
new Thread(this::apply).start();
}
}

加锁和释放锁的过程：

出现三个临时顺序节点，正常情况下是，00000000，00000001,00000002顺序释放锁，也
就是删除节点。

2，分布式锁使用的问题

zookeeper实现的分布式锁，解决分布式问题，不可重入问题，使用起来也较为简单。但是，存在以下问题：
（1）效率低，频繁的创建和删除节点。
因为每次在创建锁和释放锁的过程中，都要动态创建、销毁瞬时节点来实现锁功能。大家知道，ZK中创建和删除节点只能通过Leader服务器来执行，然后Leader服务器还需要将数据同步到所有的Follower机器上，这样频繁的网络通信， 性能的短板是非常突出的。
所以，在高性能，高并发的场景下，不建议使用ZooKeeper的分布式锁。而由于ZooKeeper的高可用特性，所以在并发量不是太高的场景，推荐使用ZooKeeper的分布式锁。

几种方式对比

无论哪种方式都无法完美的实现。就像CAP一样，在复杂性、可靠性、性能等方面无法同时满足，所 以，根据不同的应用场景选择最适合自己的才是王道。
（1），从理解的难易程度角度（从低到高）
数据库> 缓存> Zookeeper
（2），从实现的复杂性角度（从低到高）
Zookeeper >= 缓存> 数据库
（3），从性能角度（从高到低）
缓存> Zookeeper >= 数据库
（4），从可靠性角度（从高到低）
Zookeeper > 缓存> 数据库

2，分布式锁带来的问题？
（1），将并发变成串行，降低了系统的访问效率 解决方案：具体的解决方案要根据业务去做优化。