Zookeeper 应用

数据发布/订阅

数据发布/订阅（Publish/Subscribe）系统，即所谓的配置中⼼，顾名思义就是发布者将数据发布到ZooKeeper的⼀个或⼀系列节点上，供订阅者进⾏数据订阅，进⽽达到动态获取数据的⽬的，实现配置信息的集中式管理和数据的动态更新。

发布/订阅系统⼀般有两种设计模式，分别是推（Push）模式和拉（Pull）模式。在推模式中，服务端主动将数据更新发送给所有订阅的客户端；⽽拉模式则是由客户端主动发起请求来获取最新数据，通常客户端都采⽤定时进⾏轮询拉取的⽅式。

ZooKeeper 采⽤的是推拉相结合的⽅式：客户端向服务端注册⾃⼰需要关注的节点，⼀旦该节点的数据发⽣变更，那么服务端就会向相应的客户端发送Watcher事件通知，客户端接收到这个消息通知之后，需要主动到服务端获取最新的数据。

如果将配置信息存放到ZooKeeper上进⾏集中管理，那么通常情况下，应⽤在启动的时候都会主动到ZooKeeper服务端上进⾏⼀次配置信息的获取，同时，在指定节点上注册⼀个Watcher监听，这样⼀来，但凡配置信息发⽣变更，服务端都会实时通知到所有订阅的客户端，从⽽达到实时获取最新配置信息的⽬的。

命名服务

命名服务（Name Service）也是分布式系统中⽐较常⻅的⼀类场景，是分布式系统最基本的公共服务之⼀。在分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等——这些我们都可以统称它们为名字（Name），其中较为常⻅的就是⼀些分布式服务框架（如RPC、RMI）中的服务地址列表，通过使⽤命名服务，客户端应⽤能够根据指定名字来获取资源的实体、服务地址和提供者的信息等。

ZooKeeper 提供的命名服务功能能够帮助应⽤系统通过⼀个资源引⽤的⽅式来实现对资源的定位与使⽤。另外，⼴义上命名服务的资源定位都不是真正意义的实体资源——在分布式环境中，上层应⽤仅仅需要⼀个全局唯⼀的名字，类似于数据库中的唯⼀主键。

通过调⽤ZooKeeper节点创建的API接⼝可以创建⼀个顺序节点，并且在API返回值中会返回这个节点的完整名字。利⽤这个特性，我们就可以借助ZooKeeper来⽣成全局唯⼀的ID了。

集群管理

随着分布式系统规模的⽇益扩⼤，集群中的机器规模也随之变⼤，那如何更好地进⾏集群管理也显得越来越重要了。所谓集群管理，包括集群监控与集群控制两⼤块，前者侧重对集群运⾏时状态的收集，后者则是对集群进⾏操作与控制。

Zookeeper的两大特性：
　　1.客户端如果对Zookeeper的数据节点注册Watcher监听，那么当该数据节点的内容或是其⼦节点
列表发⽣变更时，Zookeeper服务器就会向订阅的客户端发送变更通知。
　　2.对在Zookeeper上创建的临时节点，⼀旦客户端与服务器之间的会话失效，那么临时节点也会被⾃动删除
　　
利⽤其两⼤特性，可以实现集群机器存活监控系统，若监控系统在/clusterServers节点上注册⼀个Watcher监听，那么但凡进⾏动态添加机器的操作，就会在/clusterServers节点下创建⼀个临时节点：/clusterServers/[Hostname]，这样，监控系统就能够实时监测机器的变动情况。

Master选举

Master选举是⼀个在分布式系统中⾮常常⻅的应⽤场景。分布式最核⼼的特性就是能够将具有独立计算能⼒的系统单元部署在不同的机器上，构成⼀个完整的分布式系统。⽽与此同时，实际场景中往往也需要在这些分布在不同机器上的ᇿ⽴系统单元中选出⼀个所谓的“⽼⼤”，在计算机中，我们称之为Master。

在分布式系统中，Master往往⽤来协调集群中其他系统单元，具有对分布式系统状态变更的决定权。例如，在⼀些读写分离的应⽤场景中，客户端的写请求往往是由 Master来处理的；⽽在另⼀些场景中，Master则常常负责处理⼀些复杂的逻辑，并将处理结果同步给集群中其他系统单元。Master选举可以说是ZooKeeper最典型的应⽤场景了。

了ZooKeeper创建节点的API接⼝，其中⼀个重要特性便是：利⽤ZooKeeper的强⼀致性，能够很好保证在分布式⾼并发情况下节点的创建⼀定能够保证全局唯⼀性，即ZooKeeper将会保证客户端⽆法重复创建⼀个已经存在的数据节点。也就是说，如果同时有多个客户端请求创建同⼀个节点，那么最终⼀定只有⼀个客户端请求能够创建成功。利⽤这个特性，就能很容易地在分布式环境中进⾏Master选举了。

分布式锁

分布式锁是控制分布式系统之间同步访问共享资源的⼀种⽅式。如果不同的系统或是同⼀个系统的不同主机之间共享了⼀个或⼀组资源，那么访问这些资源的时候，往往需要通过⼀些互斥⼿段来防⽌彼此之间的⼲扰，以保证⼀致性，在这种情况下，就需要使⽤分布式锁了。在平时的实际项⽬开发中，我们往往很少会去在意分布式锁，⽽是依赖于关系型数据库固有的排他性来实现不同进程之间的互斥。这确实是⼀种⾮常简便且被⼴泛使⽤的分布式锁实现⽅式。然⽽有⼀个不争的事实是，⽬前绝⼤多数⼤型分布式系统的性能瓶颈都集中在数据库操作上。因此，如果上层业务再给数据库添加⼀些额外的锁，例如⾏锁、表锁甚⾄是繁重的事务处理，那么就会让数据库更加不堪重负。下⾯我们来看看使⽤ZooKeeper如何实现分布式锁，这⾥主要讲解排他锁和共享锁两类分布式锁。

排他锁

排他锁（Exclusive Locks，简称 X 锁），⼜称为写锁或ᇿ占锁，是⼀种基本的锁类型。如果事务 T1对数据对象 O1加上了排他锁，那么在整个加锁期间，只允许事务 T1对 O1进⾏读取和更新操作，其他任何事务都不能再对这个数据对象进⾏任何类型的操作——直到T1释放了排他锁。
① 定义锁
在通常的Java开发编程中，有两种常⻅的⽅式可以⽤来定义锁，分别是synchronized机制和JDK5提供的ReentrantLock。然⽽，在ZooKeeper中，没有类似于这样的API可以直接使⽤，⽽是通过 ZooKeeper上的数据节点来表示⼀个锁，例如/exclusive_lock/lock节点就可以被定义为⼀个锁。
② 获取锁
在需要获取排他锁时，所有的客户端都会试图通过调⽤ create（）接⼝，在/exclusive_lock节点下创建临时⼦节点/exclusive_lock/lock。在前⾯，我们也介绍了，ZooKeeper 会保证在所有的客户端中，最只有⼀个客户端能够创建成功，那么就可以认为该客户端获取了锁。同时，所有没有获取到锁的客户端就需要到/exclusive_lock 节点上注册⼀个⼦节点变更的Watcher监听，以便实时监听到lock节点的变更情况。
③释放锁
在“定义锁”部分，我们已经提到，/exclusive_lock/lock 是⼀个临时节点，因此在以下两种情况下，都有可能释放锁。 · 当前获取锁的客户端机器发⽣宕机，那么ZooKeeper上的这个临时节点就会被移除。 ·正常执⾏完业务逻辑后，客户端就会主动将⾃⼰创建的临时节点删除。 ⽆论在什么情况下移除了lock节点，ZooKeeper都会通知所有在/exclusive_lock节点上注册了⼦节点变更Watcher监听的客户端。这些客户端在接收到通知后，再次重新发起分布式锁获取，即重复“获取锁”过程。

共享锁

共享锁（Shared Locks，简称S锁），⼜称为读锁，同样是⼀种基本的锁类型。如果事务T1对数据对象O1加上了共享锁，那么当前事务只能对O1进⾏读取操作，其他事务也只能对这个数据对象加共享锁——直到该数据对象上的所有共享锁都被释放。共享锁和排他锁最根本的区别在于，加上排他锁后，数据对象只对⼀个事务可⻅，⽽加上共享锁后，数据对所有事务都可⻅。下⾯我们就来看看如何借助ZooKeeper来实现共享锁。
① 定义锁
和排他锁⼀样，同样是通过 ZooKeeper 上的数据节点来表示⼀个锁，是⼀个类似于“/shared_lock/[Hostname]-请求类型-序号”的临时顺序节点，例如/shared_lock/host1-R-0000000001，那么，这个节点就代表了⼀个共享锁。
② 获取锁
在需要获取共享锁时，所有客户端都会到/shared_lock 这个节点下⾯创建⼀个临时顺序节点，如果当前是读请求，那么就创建例如/shared_lock/host1-R-0000000001的节点；如果是写请求，那么就创建例如/shared_lock/host2-W-0000000002的节点。

通过Zookeeper来确定分布式读写顺序，⼤致分为四步

1. 创建完节点后，获取/shared_lock节点下所有⼦节点，并对该节点变更注册监听。
2. 确定⾃⼰的节点序号在所有⼦节点中的顺序。
3. 对于读请求：若没有⽐⾃⼰序号⼩的⼦节点或所有⽐⾃⼰序号⼩的⼦节点都是读请求，那么表明⾃⼰已经成功获取到共享锁，同时开始执⾏读取逻辑，若有写请求，则需要等待。对于写请求：若⾃⼰不 是序号最⼩的⼦节点，那么需要等待。
4. 接收到Watcher通知后，重复步骤1

③ 释放锁
其释放锁的流程与独占锁⼀致。