面试题:Zookeeper实现分布式锁的原理

·  阅读 742
面试题:Zookeeper实现分布式锁的原理

前言

在面字节跳动时,遇到了这道面试题:如何用 Zookeeper 实现分布式锁?

相信大部分面试都是说用 Redis 去实现分布式锁,用 Zookeeper 实现分布式锁相对而言遇到的较少,最近在整理之前的面经答案,因此特意写篇博客解释一下。

实现一把分布式锁通常有很多方法,比较常见的有 redis 和 Zookeeper。相信大家对 redis 实现分布式锁已经非常了解,今天介绍的是如何通过 Zookeeper 去实现一把分布式锁。

首先 Zookeeper 为什么能实现一把分布式锁呢?这是因为它有一个特性,就是多个线程去 Zookeeper 里面去创建同一个节点的时候,只会有一个线程去执行成功。

字节跳动内推

Zookeeper 的 ZNode 节点

在了解 Zookeeper 实现分布式锁之前,首先,我们需要了解 Zookeeper 里面节点相关的知识。

Zookeeper 里面的节点可以分为两大类,一种是临时节点,一种是持久化节点。

临时节点,指的是节点创建后,如果创建节点的客户端和 Zookeeper 服务端的会话失效(例如断开连接),那么节点就会被删除。

持久化节点指的是节点创建后,即使创建节点的客户端和 Zookeeper 服务端的会话失效(例如断开连接),节点也不会被删除,只有客户端主动发起删除节点的请求,节点才会被删除。

另外还有一种节点叫做有序节点,这种节点在创建时会有一个序号,这个序号是自增的。有序节点既可以是有序临时节点,也可以是有序持久化节点。

Zookeeper 中所有的数据都是通过节点来存储的,它的目录结构就像一个文件树,如下图。

Zookeeper结构

图中的 locks、register、data 这几个目录自定义创建的,分别用来存储不同业务的数据,例如 locks 用来存放分布式锁相关的信息,register 用来存放注册中心相关的数据。

如何实现

采用 Zookeeper 实现分布式锁,有两种方案:1. 基于临时节点实现; 2. 基于临时顺序节点实现。下面以及介绍这种方案的实现原理。

首先,假设所有的分布式锁都存储在 locks 这个目录中。

方案一:基于临时节点实现(不推荐)

假设现在有客户端 A、B、C 均来获取同一把分布式锁:Key1。

  1. 首先,客户端 A 来获取分布式锁 Key1,那么它就会尝试在 locks 这个目录下去创建一个叫做 Key1 的 ZNode 节点。如果这个时候 locks 目录里面没有 Key1 这个 ZNode 节点,那么客户端 A 就能成功创建 Key1 节点,这就表示客户端 A 成功获取到了 Key1 这把锁锁。

图1

  1. 同时,客户端 B 也来获取 Key1 这把锁。客户端 B 也需要去 locks 这个目录里面去创建 Key1 ZNode 节点,这个时候,由于 Key1 这个 ZNode 节点已经存在,所以客户端 B 就会创建失败。而创建失败就表示客户端 B 获取锁失败,所以这个时候客户端 B 就会向 Zookeeper 注册自己的监听器(Watcher),监听 Key1 这个 ZNode 节点的变化(当 Key1 节点发生变化时,Zookeeper 会通知到客户端 B)。

如果客户端 A 和客户端 B,是同时请求到 Zookeeper,那么 Zookeeper 它有一个机制,它会保证只会有其中一个客户端能创建成功 Key1 这个 ZNode 节点。

图2

  1. 同理,此时客户端 C 来获取 Key1 锁时,也是无法获取到锁,也会把自己的 Watcher 注册到 ZK 中,监听 Key1 这个 ZNode 节点的变化。
  2. 当客户端 A 处理完自己的业务逻辑之后,那么就会执行释放锁的操作。释放锁时,客户端删除 Key1 节点,如果节点删除成功就表示锁释放成功。当 Key1 这个节点被删除后,Zookeeper 就会通知所有监听 Key1 这个节点的客户端,也就是客户端 B、C。
  3. 当客户端闭 B 和 C 接到通知以后,知道 Key1 节点发生了变化,这个时候它们就会重新去请求 Zookeeper,尝试在 locks 目录下面创建 Key1 节点,这个时候也只会有一个客户端创能成功创建 Key1 节点。假如说是客户端 B 创建成功了,那么就表示客户端 B 成功获取到了锁.客户端 C 获取锁失败,那么就继续去监听 Key1 这个节点的变化。

图3

为什么不推荐

以上就是基于临时节点这个方案去实现 Zookeeper 分布式锁,但是这个方案通常是不被推荐的。为什么呢?这是因为使用这个方案会存在一个很大的问题:羊群效应。

什么意思呢?

从上面的过程中我们可以看到,当客户端 A 释放锁成功以后,Zookeeper 需要去通知所有监听 Key1 这个节点的客户端。上面我们的例子中只有客户端 B 和客户端 C,但是在实际应用中可能有成百上千个客户端,甚至更多。Zookeeper 在这一瞬间需要发送成百上千个请求,首先这个效率显然是不高的,另外当分布式锁的竞争较为激烈时,极有可能在这一瞬间 Zookeeper 的网卡可能被撑爆。而且系统中可能并不仅仅存 Key1 这一把锁,还会存在 Key2、Key3、Key4...,这些锁也会存在竞争,Zookeeper 的压力会更大。

在这个过程中,我们很明显地能感觉到这是不合理的,因为获取分布式锁时肯定是只有其中一个客户端能获取到,那么当 Key1 这个节点被删除以后,需要通知其他的客户端来获取锁,这个时候我们有必要去通知所有的客户端吗?

显然是没有必要的,我们只需要通知其中一个客户端就可以了。因此方案二出现了。

方案二:基于临时顺序节点实现(推荐)

基于临时顺序节点去实现分布式锁时,就不是在 Linux 这个目录下面创建 Key1 这个临时节点了。而是先在 locks 这个目录下面创建一个 Key1 目录,然后在 Key1 目录里面去创建临时顺序节点。

  1. 假设现在客户端 a 来获取分布式锁 Key1,那么这个时候客户端 A 就会在 Key1 这个目录里面创建一个临时顺序节点,这个临时顺序节点的序号是 001。
  2. 然后客户端 A 会判断自己创建的这个临时顺序节点 001 在 Key1 这个目录里面,它的序号是不是最小的?如果是最小的,那么就表示客户端 A 获取锁成功。
  3. 接着客户端 B 也来获取 Key1 这个分布式锁,它也会在 Key1 这个目录下面去创建一个临时顺序节点,由于这个时候自增序号已经变为 002 了,因为之前已经创建过 001 了,所以客户端 B 会创建 002 这个临时顺序节点。

图4

  1. 同理,客户端 B 也会判断自己当前创建的临时顺序节点 002,是不是当前 Key1 目录中序号最小的临时节点,显然不是,因为前面有一个 001 临时顺序节点,所以客户端 B 这个时候是获取锁失败。
  2. 当客户端 B 获取锁失败之后,它会把自己的监听器注册到 Zookeeper,它监听的是它前面一个临时顺序节点,也就是 001 这个顺序节点。

图5

  1. 此时如果客户端 C 也来获取分布式锁 Key1,这个时候它就会在 Key 目录中创建临时顺序节点 003,同样 003 也不是序号最小的临时顺序节点,所以客户端 C 也获取锁失败,接着它会去监听 002 这个临时顺序节点。

  2. 当客户端 A 处理完业务逻辑之后,它就会去释放锁。释放锁的操作就是去删除 Key1 这个目录下面客户端 A 所创建的临时顺序节点,也就是删除 001 这个临时顺序节点。当 001 这个顺序节点被删除以后,Zookeeper 就会去通知监听 001 这个顺序节点的所有客户端,也就是通知客户端 B。客户端 B 接收到 Zookeeper 的通知之后,它就会去判断我当前创建的临时顺序节点 002 是不是当前 Key1 这个目录中序号最小的一个临时顺序节点。此时由于 001 这个顺序节点已经不存在了,显然 002 是最小的了,因此客户端 B 就获取锁成功。

  1. 同样当客户端 B 释放锁之后,就会将 002 删除,002 删除以后,Zookeeper 会通知客户端 C,客户端 C 发现我当前创建的临时顺序节点 003 是 Key1 这个目录里面最小的序号,所以客户端 C 获取锁成功。

思考

  1. 当客户端 A 获取锁成功以后,长时间不释放锁,或者说客户端 A 所在的机器宕机,或者客户端 A 所在的机器出现网络故障,这个时候会出现什么状况?

当客户端 A 所在的机器出现宕机,或者出现网络故障后,长时间不和 Zookeeper 通信的时候,客户端 A 和 Zookeeper 之间创建的 Session 就会失效,当这个 Session 失效以后,Zookeeper 会将客户端 A 所创建的临时顺序节点给直接删除,这个时候其他的客户端就能正常获取锁了。

推荐

内推

分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改