Zookeeper分布式锁的实现

Zookeeper分布式锁的实现

本文主要介绍分布式锁的概念及常见实现方式，并重点基于Zookeeper实现分布式锁。

一、什么是分布式锁

1、单机情况下

在单进程的系统中，当存在多个线程同时改变某个共享变量时，就需要对变量或代码块做同步，我们可以使用synchronize或者Lock等锁住代码块，使多个线程在修改这种变量时能够顺序执行防止并发修改变量造成的数据不一致问题。单机情况下线程之间共享内存，只要使用线程锁就可以解决并发问题。

2、分布式情况下

目前几乎很多大型网站及应用都是分布式部署的，分布式与单机情况下最大的不同在于其不是多线程而是多进程。多线程由于可以共享堆内存，进程之间甚至可能都不在同一台物理机上，线程A和线程B很可能不是在同一JVM中，这样线程锁就无法起到作用了，因此需要将“锁标识”存储在一个所有进程都能看到的地方，比如数据库、redis、zk等，这时候就要用到分布式锁来解决。

二、分布式锁的特点

1、要保证加锁的方案同一时刻只能被一台机器上的一个线程访问。
2、获取锁的客户端若因为宕机而未能释放锁，其它客户端也能获取到该锁。
3、锁只能被持有该锁的客户端删除，不能由其它客户端删除。
4、最好是阻塞锁，即让线程进入阻塞状态以等待获取锁 。

三、分布式锁的几种实现

一般的实现方式有数据库、redis、zookeeper三种：
1、数据库可以利用唯一索引、乐观锁实现
2、redis可以利用原子命令或者Redission实现
3、zookeeper主要利用其临时顺序节点及watcher机制实现。
数据库及redis的实现本文不再赘述，重点介绍基于zookeeper的分布式锁实现方法。

四、ZK基本介绍

1、zk节点特性

zookeeper中的数据节点（ZNode）是按照“树”结构进行存储的，类似于文件目录结构。znode是由客户端创建的，分为4中不同的类型：

2、节点操作常用API

zookeeper不支持级联创建节点，需存在父节点再创建子节点；父节点为临时节点时不能为其创建子节点。

3、watcher机制

1）watcher原理

ZooKeeper 的 Watcher 机制主要包括客户端进程、客户端 WatchManager 和 ZooKeeper 服务器三部分。 在具体流程上，客户端在向 ZooKeeper 服务器注册 Watcher 的同时，会将 Watcher 对象存储在客户端的 WatchManager 中。当ZooKeeper 服务器触发 Watcher 事件后，会向客户端发送通知，客户端线程从 WatchManager 的实现类中取出对应的 Watcher 对象来执行回调逻辑，统一在重载的process方法针对不同Watcher事件做处理。

2）watcher事件

ZooKeeper可以为exists()、getChildren()及getData()这些读操作设置watcher，也就是这类函数除了函数本身的功能之外，还能够注册watcher事件。

3）watcher特性

• 一次触发
  当设置监视的数据发生改变时，该监视事件会被发送到客户端，但Watcher是一次性的，一旦被触发就会移除，再次使用时需要重新注册。
  例如，如果客户端调用了 getData("/znode1", true) 并且稍后 /znode1 节点上的数据发生了改变或者被删除了，客户端将会获取到 /znode1 发生变化的监视事件，而如果 /znode1 再一次发生了变化，除非客户端再次对 /znode1 设置监视，否则客户端不会收到事件通知。
• 顺序执行
  Zookeeper 客户端和服务端是通过 socket 进行通信，客户端 Watcher 回调的过程是一个串行同步的过程，为我们保证了顺序。
• 轻量级
  Watcher 通只会告诉客户端发生了事件，而不会说明事件的具体内容。例如针对 NodeDataChanged 事件，ZooKeeper 的Watcher 只会通知客户端指定数据节点的数据内容发生了变更，而对于原始数据以及变更后的新数据都无法从这个事件中直接获取到，而是需要客户端主动重新去获取数据。

五、zk分布式锁实现思路

Zk分布式锁的思路可以类比日常生活中在超时排队付款的场景：
1、每个请求都去zk创建一个临时顺序节点，可以拿到当前请求的序号
2、查看当前序号是不是最小的：如果是最小就可以获得锁处理业务，业务处理完成后删除锁，以便后续请求使用
3、如果不是最小的则对前一个节点序号设置watcher。当前一个请求处理完成，对应节点删除后watcher触发，当前请求可再次进行第2步

六、核心代码

1、创建临时顺序节点

2、判断是否最小

3、设置watcher

4、watcher事件处理

5、运行结果

可以看到临时节点的创建顺序（请求顺序）即为执行顺序

6、框架实现

zk客户端框架curator封装了相关实现，有兴趣的同学可另了解，本文不再举例

七、优缺点对比

优点

1、zookeeper天生设计保证数据一致性，适合实现分布式锁。
2、zookeeper的数据可以支持临时节点的概念，即客户端写入的数据是临时数据，在客户端宕机后，临时数据会被删除，这样就实现了锁的异常释放。使用这样的方式，就不需要给锁增加超时自动释放的特性了。
3、通过watcher通知机制无需手动实现阻塞场景，且性能消耗较小，其他方式需要自行实现轮循。

缺点

整体性能方面不如redis高。有较多的客户端频繁的申请加锁、释放锁，对于 ZK 集群的压力会比较大