Distributed System: ZooKeeper系列之三 （Master选举和分布式锁）

这期文章，参考Linux 爱好者公众号的文章《ZooKeeper原理及其在Hadoop和Hbase中的应用》而归纳整理的。

其实，Master的选举和分布式锁属于ZooKeeper实现的分布式系统的功能。

下面继续来讲讲这两个常用的应用场景。

Master选举：

Master选举可以说是ZooKeeper最典型的应用场景了。比如HDFS中Active NameNode的选举、YARN中Active ResourceManager的选举和HBase中Active HMaster的选举等。

Master选举也是充分利用了临时ZNode的特点。在讲述Zookeeper的Master选举前，先说说一般的Master选举过程。

通常情况下，我们可以选择常见的关系型数据库中的主键特性来实现：希望成为Master的机器都向数据库中插入一条相同主键ID的记录，数据库会帮我们进行主键冲突检查，也就是说，只有一台机器能插入成功——那么，我们就认为向数据库中成功插入数据的客户端机器成为Master。

那么，ZooKeeper则是通过ZNode来实现这一过程。ZooKeeper能会保证客户端无法创建一个已经存在的ZNode。也就是说，如果同时有多个客户端请求创建同一个临时节点，那么最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很容易地在分布式环境中进行Master选举了。

ZooKeeper将会保证客户端无法创建一个已经存在的ZNode。也就是说，如果同时有多个客户端请求创建同一个临时节点，那么最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很容易地在分布式环境中进行Master选举了。

这也是ZooKeeper比关系型数据库要强的地方。普通的关系型数据库一旦Master挂了，就无法通知其他的Slaves说其挂了。

分布式锁：

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。

分布式锁又分为排他锁（写锁）和共享锁（读锁）两种。

排他锁

排他锁（Exclusive Locks，简称X锁），又称为写锁或独占锁。

如果事务T1对数据对象O1加上了排他锁，那么在整个加锁期间，只允许事务T1对O1进行读取和更新操作，其他任何事务都不能在对这个数据对象进行任何类型的操作（不能再对该对象加锁），直到T1释放了排他锁。

可以看出，排他锁的核心是如何保证当前只有一个事务获得锁，并且锁被释放后，所有正在等待获取锁的事务都能够被通知到。

共享锁

共享锁（Shared Locks，简称S锁），又称为读锁。如果事务T1对数据对象O1加上了共享锁，那么T1只能对O1进行读操作，其他事务也能同时对O1加共享锁（不能是排他锁），直到O1上的所有共享锁都释放后O1才能被加排他锁。

ZooKeeper如何实现锁机制呢？

没错，又是通过ZNode来实现。

定义：

ZooKeeper上的一个ZNode可以表示一个锁。例如/exclusive_lock/lock节点就可以被定义为一个锁。

获得：

获得锁就通过创建ZNode的方式来实现。所有客户端都去/exclusive_lock节点下创建临时子节点/exclusive_lock/lock。ZooKeeper会保证在所有客户端中，最终只有一个客户端能够创建成功，那么就可以认为该客户端获得了锁。所有没有获取到锁的客户端就需要到/exclusive_lock节点上注册一个子节点变更的Watcher监听，以便实时监听到lock节点的变更情况。

释放：

因为/exclusive_lock/lock是一个临时节点，因此在以下两种情况下，都有可能释放锁。

当前获得锁的客户端机器发生宕机或重启，那么该临时节点就会被删除，释放锁。

正常执行完业务逻辑后，客户端就会主动将自己创建的临时节点删除，释放锁。

无论在什么情况下移除了lock节点，ZooKeeper都会通知所有在/exclusive_lock节点上注册了节点变更Watcher监听的客户端。这些客户端在接收到通知后，再次重新发起分布式锁获取，即重复『获取锁』过程。