ZooKeeper实现分布式锁

Published: 26 Oct 2019 Category: ZooKeeper

一、原理

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

Zookeeper分布式锁恰恰应用了临时顺序节点。

1.1 获取锁

首先,在Zookeeper当中创建一个持久节点ParentLock。当第一个客户端Client1想要获得锁时,需要在ParentLock这个节点下面创建一个临时顺序节点 Lock1。

/
|_ParentLock
    |_Lock1

之后,Client1查找ParentLock下面所有的临时顺序节点并排序,判断自己所创建的节点Lock1是不是顺序最靠前的一个。如果是第一个节点,则成功获得锁。

这时候,如果再有一个客户端 Client2 前来获取锁,则在ParentLock下载再创建一个临时顺序节点Lock2。

/
|_ParentLock
    |_Lock1
    |_Lock2

Client2查找ParentLock下面所有的临时顺序节点并排序,判断自己所创建的节点Lock2是不是顺序最靠前的一个,结果发现节点Lock2并不是最小的。

于是,Client2向排序仅比它靠前的节点Lock1注册Watcher,用于监听Lock1节点是否存在。这意味着Client2抢锁失败,进入了等待状态。 

/
|_ParentLock
    |_Lock1     <-- watched by Client2
    |_Lock2  

这时候,如果又有一个客户端Client3前来获取锁,则在ParentLock下载再创建一个临时顺序节点Lock3。

/
|_ParentLock
    |_Lock1
    |_Lock2
    |_Lock3

Client3查找ParentLock下面所有的临时顺序节点并排序,判断自己所创建的节点Lock3是不是顺序最靠前的一个,结果同样发现节点Lock3并不是最小的。

于是,Client3向排序仅比它靠前的节点Lock2注册Watcher,用于监听Lock2节点是否存在。这意味着Client3同样抢锁失败,进入了等待状态。 

/
|_ParentLock
    |_Lock1     <-- watched by Client2
    |_Lock2     <-- watched by Client3
    |_Lock3

这样一来,Client1得到了锁,Client2监听了Lock1,Client3监听了Lock2。这恰恰形成了一个等待队列,很像是Java当中ReentrantLock所依赖的AQS(AbstractQueuedSynchronizer)。

获得锁的过程大致就是这样,那么Zookeeper如何释放锁呢?

1.2 释放锁

释放锁的过程很简单,只需要释放对应的子节点就好。

释放锁分为两种情况:

1.2.1 任务完成,客户端显示释放

当任务完成时,Client1会显示调用删除节点Lock1的指令。

1.2.2 任务执行过程中,客户端崩溃

此时,根据临时节点的特性,相关联的节点Lock1会随之自动删除。

由于Client2一直监听着Lock1的存在状态,当Lock1节点被删除,Client2会立刻收到通知。这时候Client2会再次查询ParentLock下面的所有节点,确认自己创建的节点Lock2是不是目前最小的节点。如果是最小,则Client2顺理成章获得了锁。

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

二、对比Redis实现的分布式锁

|分布式锁 | 优点 | 缺点| |–|–|–| Zookeeper |1.有封装好的框架,容易实现
2.有等待锁的队列,大大提升抢锁效率。|添加和删除节点性能较低 |Redis |Set和Del指令性能较高 | 1.实现复杂,需要考虑超时,原子性,误删等情形。
2.没有等待锁的队列,只能在客户端自旋来等待,效率低下。

REF

Zookeeper实现分布式锁
zookeeper 实现分布式锁安全用法