面试题：zookeeper实现分布式锁

标签：变化   session   地方   缺点   创建   建立   无法   节点   node   

zookeeper实现分布式锁

Zookeeper是一种提供配置管理、分布式协同以及命名的中心化服务。
zk的模型是这样的：zk包含一系列的节点，叫做znode，就好像文件系统一样每个znode表示一个目录，然后znode有一些特性：

• 有序节点：假如当前有一个父节点为 /lock ，我们可以在这个父节点下面创建子节点；zookeeper提供了一个可选的有序特性，例如我们可以创建子节点“/lock/node-”并且指明有序，那么zookeeper在生成子节点时会根据当前的子节点数量自动添加整数序号也就是说，如果是第一个创建的子节点，那么生成的子节点为 /lock/node-0000000000 ，下一个节点则为 /lock/node-0000000001 ，依次类推。
• 临时节点：客户端可以建立一个临时节点，在会话结束或者会话超时后，zookeeper会自动删除该节点。
• 事件监听：在读取数据时，我们可以同时对节点设置事件监听，当节点数据或结构变化时，zookeeper会通知客户端。当前zookeeper有如下四种事件：
  • 节点创建
  • 节点删除
  • 节点数据修改
  • 子节点变更

基于以上的一些zk的特性，我们很容易得出使用zk实现分布式锁的落地方案：

1. 使用zk的临时节点和有序节点，每个线程获取锁就是在zk创建一个临时有序的节点，比如在/lock/目录下。

2. 创建节点成功后，获取/lock目录下的所有临时节点，再判断当前线程创建的节点是否是所有的节点的序号最小的节点

3. 如果当前线程创建的节点是所有节点序号最小的节点，则认为获取锁成功。

4. 如果当前线程创建的节点不是所有节点序号最小的节点，则对节点序号的前一个节点添加一个事件监听。
   比如当前线程获取到的节点序号为 /lock/003 ,然后所有的节点列表为[/lock/001,/lock/002,/lock/003] ,则对 /lock/002 这个节点添加一个事件监听器。

如果锁释放了，会唤醒下一个序号的节点，然后重新执行第3步，判断是否自己的节点序号是最小。

比如 /lock/001 释放了， /lock/002 监听到时间，此时节点集合为 [/lock/002,/lock/003] ,则 /lock/002 为最小序号节点，获取到锁。Curator是一个zookeeper的开源客户端，也提供了分布式锁的实现。

来看看锁的一些特性Zookeeper是否满足：

• 互斥：因为只有一个最小节点，满足互斥特性
• 锁释放：使用Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。
• 阻塞锁：使用Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。
• 可重入：使用Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。
• 高可用：使用Zookeeper可以有效的解决单点问题，ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。
• 高性能：Zookeeper集群是满足强一致性的，因此就会牺牲一定的性能，与Redis相比略显不足

总结：

• 优点：使用非常简单，不用操心释放问题、阻塞获取问题
• 缺点：性能比Redis稍差一些

面试题：zookeeper实现分布式锁

标签：变化   session   地方   缺点   创建   建立   无法   节点   node   

原文地址：https://www.cnblogs.com/dalianpai/p/14425608.html