面试官：ZK（ZooKeeper）分布式锁实现，你了解了吗？

准备

本文会使用到 三台 独立服务器，可以自行提前搭建好。

不知道如何搭建的，可以看我之前 ZooKeeper集群 搭建：Zookeeper 集群部署的那些事儿

关于ZooKeeper 一些基础命令可以看这篇：Zookeeper入门看这篇就够了

前言

在平时我们对锁的使用，在针对单个服务，我们可以用 Java 自带的一些锁来实现，资源的顺序访问，但是随着业务的发展，现在基本上公司的服务都是多个，单纯的 Lock或者Synchronize 只能解决单个JVM线程的问题，那么针对于单个服务的 Java 的锁是无法满足我们业务的需要的，为了解决多个服务跨服务访问共享资源，于是就有了分布锁，分布式锁产生的原因就是集群。

正文

实现分布式锁的方式有哪些呢？

• 分布式锁的实现方式主要以（ZooKeeper、Reids、Mysql）这三种为主

今天我们主要讲解的是使用 ZooKeeper来实现分布式锁，ZooKeeper的应用场景主要包含这几个方面：

1. 服务注册与订阅（共用节点）
2. 分布式通知（监听ZNode）
3. 服务命令（ZNode特性）
4. 数据订阅、发布（Watcher）
5. 分布式锁（临时节点）

ZooKeeper实现分布式锁，主要是得益于ZooKeeper 保证了数据的强一致性，锁的服务可以分为两大类：

• 保持独占所有试图来获取当前锁的客户端，最终有且只有一个能够成功得到当前锁的钥匙，通常我们会把 ZooKeeper 上的节点（ZNode）看做一把锁，通过 create 临时节点的方式来实现，当多个客户端都去创建一把锁的时候，那么只有成功创建了那个客户端才能拥有这把锁
• 控制时序所有试图获取锁的客户端，都是被顺序执行，只是会有一个序号（zxid），我们会有一个节点，例如：/testLock，所有临时节点都在这个下面去创建，ZK的父节点(/testLock) 维持了一个序号，这个是ZK自带的属性，他保证了子节点创建的时序性，从而也形成了每个客户端的一个 全局时序

ZK锁机制

在实现ZooKeeper 分布式锁之前我们有必要了解一下，关于ZooKeeper分布式锁机制的实现流程和原理，不然各位宝贝，出去面试的时候怎么和面试官侃侃而谈~

临时顺序节点

基于ZooKeeper的临时顺序节点 ，ZooKeeper比较适合来实现分布式锁：

• 顺序发号器： ZooKeeper的每一个节点，都是自带顺序生成器：在每个节点下面创建临时节点，新的子节点后面，会添加一个次序编号，这个生成的编号，会在上一次的编号进行 +1 操作
• 有序递增： ZooKeeper节点有序递增，可以保证锁的公平性，我们只需要在一个持久父节点下，创建对应的临时顺序节点，每个线程在尝试占用锁之前，会调用watch，判断自己当前的序号是不是在当前父节点最小，如果是，那么获取锁
• Znode监听： 每个线程在抢占所之前，会创建属于当前线程的ZNode节点，在释放锁的时候，会删除创建的ZNode，当我们创建的序号不是最小的时候，会等待watch通知，也就是上一个ZNode的状态通知，当前一个ZNode删除的时候，会触发回调机制，告诉下一个ZNode，你可以获取锁开始工作了
• 临时节点自动删除：ZooKeeper还有一个好处，当我们客户端断开连接之后，我们出创建的临时节点会进行自动删除操作，所以我们在使用分布式锁的时候，一般都是会去创建临时节点，这样可以避免因为网络异常等原因，造成的死锁。
• 羊群效应：