【七张图】彻底讲清楚ZooKeeper分布式锁的实现原理
一、写在前面 之前写过一篇文章( 《拜托,面试请不要再问我Redis分布式锁的实现原理》 ),给大家说了一下Redisson这个开源框架是如何实现Redis分布式锁原理的,这篇文章再给大家聊一下ZooKeeper实现分布式锁的原理。 同理,我是直接基于比较常用的 Curator 这个开源框架,聊一下这个框架对ZooKeeper(以下简称zk)分布式锁的实现。 一般除了大公司是自行封装分布式锁框架之外,建议大家用这些开源框架封装好的分布式锁实现,这是一个比较快捷省事儿的方式。 二、ZooKeeper分布式锁机制 接下来我们一起来看看,多客户端获取及释放zk分布式锁的整个流程及背后的原理。 首先大家看看下面的图,如果现在有两个客户端一起要争抢zk上的一把分布式锁,会是个什么场景? 如果大家对zk还不太了解,建议先百度一下,快速了解一些基本概念,比如zk有哪些节点类型等等。 参见上图。zk里有一把锁,这个锁就是zk上的一个节点。然后呢,两个客户端都要来获取这个锁,具体是怎么来获取呢? 咱们就假设客户端A抢先一步,对zk发起了加分布式锁的请求,这个加锁请求是用到了zk中的一个特殊的概念,叫做 “临时顺序节点”。 简单来说,就是直接在"my_lock"这个锁节点下,创建一个顺序节点,这个顺序节点有zk内部自行维护的一个节点序号。 比如说,第一个客户端来搞一个顺序节点,zk内部会给起个名字叫做