Zookeeper原理--分布式锁

怼烎@ 2022-10-24 14:28 163阅读 0赞

原文网址：[Zookeeper原理--分布式锁\_IT利刃出鞘的博客-CSDN博客][Zookeeper_--_IT_-CSDN]

# 其他网址 #

> [三种实现分布式锁的方式\_vincent-CSDN博客\_分布式锁][vincent-CSDN]、

# 简介 #

## 节点 ##

**其他网址**

> 《从Paxos到Zookeeper 分布式一致性原理与实践》=> 4.1.3 ZooKeeper的基本概念

让我们来回顾一下Zookeeper节点的概念：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlaXlpbmcwY2FuZ2xhbmc_size_16_color_FFFFFF_t_70][]

Zookeeper的数据存储结构就像一棵树，这棵树由节点组成，这种节点叫做Znode。Znode分为四种类型：

**1.持久节点 （PERSISTENT）**

默认的节点类型。创建节点的客户端与Zookeeper断开连接后，该节点依旧存在 。

**2.持久顺序节点（PERSISTENT\_SEQUENTIAL）**

所谓顺序节点，就是在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号：

![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper]

**3.临时节点（EPHEMERAL）**

和持久节点相反，当创建节点的客户端与zookeeper断开连接后，临时节点会被删除：

![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper 1]

![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper 2]

![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper 3]

**4.临时顺序节点（EPHEMERAL\_SEQUENTIAL）**

顾名思义，临时顺序节点结合和临时节点和顺序节点的特点：在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号；当创建节点的客户端与zookeeper断开连接后，临时节点会被删除。

**问题及解决方法**

<table> 
 <tbody> 
  <tr> 
   <td style="width:220px;"><strong>问题</strong></td> 
   <td><strong>解决方法</strong></td> 
  </tr> 
  <tr> 
   <td style="width:220px;">锁无法释放</td> 
   <td>Zookeeper可以有效的解决锁无法释放的问题，因为在创建锁的时候，客户端会在ZK中创建一个临时节点，一旦客户端获取到锁之后突然挂掉（Session连接断开），那么这个临时节点就会自动删除掉。其他客户端就可以再次获得锁。</td> 
  </tr> 
  <tr> 
   <td style="width:220px;">非阻塞锁</td> 
   <td>Zookeeper可以实现阻塞的锁，客户端可以通过在ZK中创建顺序节点，并且在节点上绑定监听器，一旦节点有变化，Zookeeper会通知客户端，客户端可以检查自己创建的节点是不是当前所有节点中序号最小的，如果是，那么自己就获取到锁，便可以执行业务逻辑了。</td> 
  </tr> 
  <tr> 
   <td style="width:220px;">不可重入</td> 
   <td>Zookeeper也可以有效的解决不可重入的问题，客户端在创建节点的时候，把当前客户端的主机信息和线程信息直接写入到节点中，下次想要获取锁的时候和当前最小的节点中的数据比对一下就可以了。如果和自己的信息一样，那么自己直接获取到锁，如果不一样就再创建一个临时的顺序节点，参与排队。</td> 
  </tr> 
  <tr> 
   <td style="width:220px;">单点问题</td> 
   <td>Zookeeper可以有效的解决单点问题，ZK是集群部署的，只要集群中有半数以上的机器存活，就可以对外提供服务。</td> 
  </tr> 
  <tr> 
   <td style="width:220px;">公平问题</td> 
   <td>Zookeeper可以解决公平锁问题，客户端在ZK中创建的临时节点是有序的，每次锁被释放时，ZK可以通知最小节点来获取锁，保证了公平。</td> 
  </tr> 
  <tr> 
   <td style="width:220px;">一致性问题</td> 
   <td>Zookeeper是一个保证了弱一致性即最终一致性的分布式组件。</td> 
  </tr> 
 </tbody> 
</table>

**优缺点**

<table> 
 <tbody> 
  <tr> 
   <td style="width:634px;"><strong>优点</strong></td> 
   <td style="width:473px;"><strong>缺点</strong></td> 
  </tr> 
  <tr> 
   <td style="width:634px;"> <p>有效解决这些问题：单点，不可重入，非阻塞、锁无法释放（不靠超时时间释放锁）。</p> <p>实现简单。</p> <p>可靠性高。</p> </td> 
   <td style="width:473px;"> <p>性能不如Redis。</p> <p></p> </td> 
  </tr> 
 </tbody> 
</table>

## **一致性** ##

Zookeeper采用称为Quorum Based Protocol的数据同步协议。假如Zookeeper集群有N台Zookeeper服务器(N通常取奇数，3台能够满足数据可靠性同时有很高读写性能，5台在数据可靠性和读写性能方面平衡最好)，那么用户的一个写操作，首先同步到N/2 + 1台服务器上，然后返回给用户，提示用户写成功。基于Quorum Based Protocol的数据同步协议决定了Zookeeper能够支持什么强度的一致性。

在分布式环境下，满足强一致性的数据储存基本不存在，它要求在更新一个节点的数据，需要同步更新所有的节点。这种同步策略出现在主从同步复制的数据库中。但是这种同步策略，对写性能的影响太大而很少见于实践。因为Zookeeper是同步写N/2+1个节点，还有N/2个节点没有同步更新，所以Zookeeper不是强一致性的。

用户的数据更新操作，不保证后续的读操作能够读到更新后的值，但是最终会呈现一致性。牺牲一致性，并不是完全不管数据的一致性，否则数据是混乱的，那么系统可用性再高分布式再好也没有了价值。牺牲一致性，只是不再要求关系型数据库中的强一致性，而是只要系统能达到最终一致性即可。

**Zookeeper是否满足最终一致性，需要看客户端的编程方式**

> **满足最终一致性编程的方法**
> 
> 1.  B进程监听Zookeeper上/z的数据变化
> 2.  A进程向Zookeeper的/z写入一个数据，成功返回前，Zookeeper需要调用注册在/z上的监听器，Leader将数据变化的通知告诉B
> 3.  B进程的事件响应方法得到响应后，去取变化的数据，那么B一定能够得到变化的值
> 4.  这里的因果一致性提现在Leader和B之间的因果一致性，也就是是Leader通知了数据有变化

> **不满足最终一致性编程的方法**
> 
> 1.  A进程向Zookeeper的/z写入一个数据，成功返回
> 2.  A进程通知B进程，A已经修改了/z的数据
> 3.  B读取Zookeeper的/z的数据
> 4.  由于B连接的Zookeeper的服务器有可能还没有得到A写入数据的更新，那么B将读不到A写入的数据

# **原理** #

Zookeeper分布式锁应用了临时顺序节点。具体如何实现呢？让我们来看一看详细步骤：

## **获取锁** ##

> 首先，在Zookeeper当中创建一个持久节点ParentLock。当第一个客户端（Client1）想要获得锁时，需要在ParentLock这个节点下面创建一个**临时顺序节点** Lock1。
> 
> ![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper 4]
> 
> 之后，Client1查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是第一个节点，则成功获得锁。
> 
> ![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper 5]
> 
> 这时候，如果再有一个客户端 Client2 前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock2。
> 
> ![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper 6]
> 
> Client2查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock2是不是顺序最靠前的一个，结果发现节点Lock2并不是最小的。
> 
> 于是，Client2向排序仅比它靠前的节点Lock1注册**Watcher**，用于监听Lock1节点是否存在。这意味着Client2抢锁失败，进入了等待状态。
> 
> ![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper 7]
> 
> 这时候，如果又有一个客户端Client3前来获取锁，则在ParentLock下载再创建一个临时顺序节点Lock3。
> 
> ![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper 8]
> 
> Client3查找ParentLock下面所有的临时顺序节点并排序，判断自己所创建的节点Lock3是不是顺序最靠前的一个，结果同样发现节点Lock3并不是最靠前的。
> 
> 于是，Client3向排序仅比它靠前的节点**Lock2**注册Watcher，用于监听Lock2节点是否存在。这意味着Client3同样抢锁失败，进入了等待状态。
> 
> ![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper 9]
> 
> 这样一来，Client1得到了锁，Client2监听了Lock1，Client3监听了Lock2。这恰恰形成了一个等待队列，很像是Java当中ReentrantLock所依赖的

## 锁的续期 ##

**其他网址**

> 《从Paxos到Zookeeper 分布式一致性原理与实践》=> 7.4.3 会话管理=> 会话激活

## **释放锁** ##

> 释放锁分为两种情况：
> 
> **1.任务完成，客户端显示释放**
> 
> 当任务完成时，Client1会显示调用删除节点Lock1的指令。
> 
> ![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper 10]
> 
> **2.任务执行过程中，客户端崩溃**
> 
> 获得锁的Client1在任务执行过程中，如果崩溃，则会断开与Zookeeper服务端的链接。根据临时节点的特性，相关联的节点Lock1会随之自动删除。
> 
> ![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper 11]
> 
> 由于Client2一直监听着Lock1的存在状态，当Lock1节点被删除，Client2会立刻收到通知。这时候Client2会再次查询ParentLock下面的所有节点，确认自己创建的节点Lock2是不是目前最小的节点。如果是最小，则Client2顺理成章获得了锁。

> ![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper 12]

> 同理，如果Client2也因为任务完成或者节点崩溃而删除了节点Lock2，那么Client3就会接到通知。

> ![「每日分享」如何用Zookeeper实现分布式锁][Zookeeper 13]

> 最终，Client3成功得到了锁。

# 问答 #

**获得了锁的JVM，一直不释放锁如何处理**

> 可以控制续命的次数，如果续命多次还是没有释放锁的话，则会超时自动释放锁，并且回滚当前事务的操作。

[Zookeeper_--_IT_-CSDN]: https://knife.blog.csdn.net/article/details/113409146
[vincent-CSDN]: https://blog.csdn.net/wuzhiwei549/article/details/80692278
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZlaXlpbmcwY2FuZ2xhbmc_size_16_color_FFFFFF_t_70]: /images/20221024/5b91894f37a84d8fa2fcfd16ff6e49f4.png
[Zookeeper]: /images/20221024/b4ddf5f37dfd40d682ceba719c3f1e9b.png
[Zookeeper 1]: /images/20221024/38d9986970d2443fa316ea3d55e237ac.png
[Zookeeper 2]: /images/20221024/9b068aa9e99d4be39547b1a15018b199.png
[Zookeeper 3]: /images/20221024/7adc295f1aa948a8b5c340bec78abc6e.png
[Zookeeper 4]: /images/20221024/30bfa7387e6a416cba1d8d26a2b25b1b.png
[Zookeeper 5]: /images/20221024/d0a67c972f4c4d769519dc30dfd8e1f8.png
[Zookeeper 6]: /images/20221024/8e81c4603ff24a6bb44fbae2aeec7fcd.png
[Zookeeper 7]: /images/20221024/e564e89ff2e642aeb13c870cc3127857.png
[Zookeeper 8]: /images/20221024/3ced13cd99af445695d8413324bafc0a.png
[Zookeeper 9]: /images/20221024/81bf66ec8b6f4612a052fb508353048f.png
[Zookeeper 10]: /images/20221024/33c155cbd02643dc898f12e892798535.png
[Zookeeper 11]: /images/20221024/96416d54ba0f4219989100e8e9b9b67c.png
[Zookeeper 12]: /images/20221024/b42a6e569c2d4556a23bec34166745d8.png
[Zookeeper 13]: /images/20221024/bee901bff79e47578c69c4859593bc3e.png