zookeeper是什么？
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，它是集群的管理者，监视着集群中各个节点的状态根据节点提交的反馈进行下一步合理操作。最终，将简单易用的接口和性能高效、功能稳定的系统提供给用户
Zookeeper工作原理
Zookeeper 的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
服务端
角色
Zookeeper中一共有以下角色：
- Leader，负责进行投票的发起和决议，更新状态和数据
- Follower，用于接收客户端请求并向客户端返回结果，在选择Leader时会进行投票
- Observer，一种功能和Follower相同，但是它不参与投票过程。它主要是为了扩展系统，提高读取速度
ZooKeeper 默认只有 Leader 和 Follower 两种角色，没有 Observer 角色。为了使用 Observer 模式，在任何想变成Observer的节点的配置文件中加入:peerType=observer 并在所有 server 的配置文件中，配置成 observer 模式的 server 的那行配置追加 :observer
Follower 和 Observer 都能提供读服务，不能提供写服务。两者唯一的区别在于， Observer机器不参与 Leader 选举过程，也不参与写操作的『过半写成功』策略，因 此 Observer 可以在不影响写性能的情况下提升集群的读性能。
leader选举
当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。
fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和 zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。
选完Leader以后，zk就进入状态同步过程
1. Leader等待server连接；
2 .Follower连接leader，将最大的zxid发送给leader；
3 .Leader根据follower的zxid确定同步点；
4 .完成同步后通知follower 已经成为uptodate状态；
5 .Follower收到uptodate消息后，又可以重新接受client的请求进行服务了
节点ZNode
每个子目录项如 NameService 都被称作为 znode(目录节点)，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的。
有四种类型的znode：
- PERSISTENT-持久化目录节点
客户端与zookeeper断开连接后，该节点依旧存在 - PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号 - EPHEMERAL-临时目录节点
客户端与zookeeper断开连接后，该节点被删除 - EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号
客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。
客户端
Session
Session 是指客户端会话，在讲解客户端会话之前，我们先来了解下客户端连接。在ZooKeeper 中，一个客户端连接是指客户端和 ZooKeeper 服务器之间的TCP长连接。
ZooKeeper 对外的服务端口默认是2181，客户端启动时，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够通过心跳检测和服务器保持有效的会话，也能够向 ZooKeeper 服务器发送请求并接受响应，同时还能通过该连接接收来自服务器的 Watch 事件通知。
Session 的 SessionTimeout 值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要SessionTimeout 规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。
Watcher
是 ZooKeeper 中一个很重要的特性。ZooKeeper允许用户在指定节点上注册一些 Watcher， 并且在一些特定事件触发的时候，ZooKeeper 服务端会将事件通知到感兴趣的客户端上去。该 机制是 ZooKeeper 实现分布式协调服务的重要特性。
import java.util.concurrent.CountDownLatch;
import org.apache.zookeeper.WatchedEvent;
import org.apache.zookeeper.Watcher;
import org.apache.zookeeper.Watcher.Event.EventType;
import org.apache.zookeeper.Watcher.Event.KeeperState;
import org.apache.zookeeper.ZooKeeper;
import org.apache.zookeeper.data.Stat;
/**
* 分布式配置中心demo
* @author
*
*/
public class ZooKeeperProSync implements Watcher {
private static CountDownLatch connectedSemaphore = new CountDownLatch(1);
private static ZooKeeper zk = null;
private static Stat stat = new Stat();
public static void main(String[] args) throws Exception {
//zookeeper配置数据存放路径
String path = "/username";
//连接zookeeper并且注册一个默认的监听器
zk = new ZooKeeper("192.168.31.100:2181", 5000, //
new ZooKeeperProSync());
//等待zk连接成功的通知
connectedSemaphore.await();
//获取path目录节点的配置数据，并注册默认的监听器
System.out.println(new String(zk.getData(path, true, stat)));
Thread.sleep(Integer.MAX_VALUE);
}
public void process(WatchedEvent event) {
if (KeeperState.SyncConnected == event.getState()) { //zk连接成功通知事件
if (EventType.None == event.getType() && null == event.getPath()) {
connectedSemaphore.countDown();
} else if (event.getType() == EventType.NodeDataChanged) { //zk目录节点数据变化通知事件
try {
System.out.println("配置已修改，新值为：" + new String(zk.getData(event.getPath(), true, stat)));
} catch (Exception e) {
}
}
}
}
}使用场景
服务发现（以Dubbo注册中心为例）
这个功能类似阿里内部的HSF使用的ConfigServer
Dubbo是集团开源的分布式服务框架，致力于提供高性能和透明化的远程服务调用解决方案和基于服务框架展开的完整SOA服务治理方案。
其中服务自动发现是最核心的模块之一，该模块提供基于注册中心的目录服务，使服务消费方能够动态的查找服务提供方，让服务地址透明化，同时服务提供方可以平滑的对机器进行扩容和缩容，其注册中心可以基于提供的外部接口来实现各种不同类型的注册中心，例如数据库、ZK和Redis等。接下来看一下基于ZK实现的Dubbo注册中心。
- /dubbo: 这是Dubbo在ZK上创建的根节点。
- /dubbo/com.foo.BarService: 这是服务节点，代表了Dubbo的一个服务。
- /dubbo/com.foo.BarService/Providers: 这是服务提供者的根节点，其子节点代表了每个服务的真正提供者。
- /dubbo/com.foo.BarService/Consumers: 这是服务消费者的根节点，其子节点代表了没一个服务的真正消费者
Dubbo基于ZK实现注册中心的工作流程：
- 服务提供者：在初始化启动的时候首先在/dubbo/com.foo.BarService/Providers节点下创建一个子节点，同时写入自己的url地址，代表这个服务的一个提供者。
- 服务消费者：在启动的时候读取并订阅ZooKeeper上/dubbo/com.foo.BarService/Providersz节点下的所有子节点，并解析所有提供者的url地址类作为该服务的地址列表，开始发起正常调用。同时在Consumers节点下创建一个临时节点，写入自己的url地址，代表自己是BarService的一个消费者
- 监控中心：监控中心是Dubbo服务治理体系的重要一部分，它需要知道一个服务的所有提供者和订阅者及变化情况。监控中心在启动的时候会通过ZK的/dubbo/com.foo.BarService节点来获取所有提供者和消费者的url地址，并注册Watcher来监听其子节点变化情况。
所有服务提供者在ZK上创建的节点都是临时节点，利用的是临时节点的生命周期和客户端会话绑定的特性，一旦提供者机器挂掉无法对外提供服务时该临时节点就会从ZK上摘除，这样服务消费者和监控中心都能感知到服务提供者的变化。
配置管理中心
数据发布与订阅，即所谓的配置中心，顾名思义就是发布者将数据发布到 ZooKeeper 节点上,供订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和动态更新。对于：数据量通常比较小。数据内容在运行时动态变化。集群中各机器共享，配置一致。这样的全局配置信息就可以发布到 ZooKeeper上，让客户端（集群的机器）去订阅该消息。发布/订阅系统一般有两种设计模式，分别是推（Push）和拉（Pull）模式。
- 推模式
服务端主动将数据更新发送给所有订阅的客户端
- 拉模式
客户端主动发起请求来获取最新数据，通常客户端都采用定时轮询拉取的方式
ZooKeeper 采用的是推拉相结合的方式：
客户端想服务端注册自己需要关注的节点，一旦该节点的数据发生变更，那么服务端就会向相应的客户端发送Watcher事件通知，客户端接收到这个消息通知后，需要主动到服务端获取最新的数据
Master选举
针对 Master 选举的需求，通常情况下，我们可以选择常见的关系型数据库中的主键特性来实现：希望成为 Master 的机器都向数据库中插入一条相同主键ID的记录，数据库会帮我们进行主键冲突检查，也就是说，只有一台机器能插入成功——那么，我们就认为向数据库中成功插入数据的客户端机器成为Master。
依靠关系型数据库的主键特性确实能够很好地保证在集群中选举出唯一的一个Master。但是，如果当前选举出的 Master 挂了，那么该如何处理？谁来告诉我 Master 挂了呢？显然，关系型数据库无法通知我们这个事件。但是，ZooKeeper 可以做到！
利用 ZooKeepr 的强一致性，能够很好地保证在分布式高并发情况下节点的创建一定能够保证全局唯一性，即 ZooKeeper 将会保证客户端无法创建一个已经存在的 数据单元节点。也就是说，如果同时有多个客户端请求创建同一个临时节点，那么最终一定只有一个客户端请求能够创建成功。利用这个特性，就能很容易地在分布式环境中进行 Master 选举了。成功创建该节点的客户端所在的机器就成为了 Master。同时，其他没有成功创建该节点的客户端，都会在该节点上注册一个子节点变更的 Watcher，用于监控当前 Master 机器是否存活，一旦发现当前的Master挂了，那么其他客户端将会重新进行 Master 选举。
这样就实现了 Master 的动态选举。
分布式锁
分布式锁是控制分布式系统之间同步访问共享资源的一种方式。如果不同系统或同一系统不同机器之间共享了同一资源，那访问这些资源时通常需要一些互斥手段来保证一致性，这种情况下就需要用到分布式锁了。
使用关系型数据库是一种简单、广泛的实现方案，但大多数大型分布式系统中数据库已经是性能瓶颈了，如果再给数据库添加额外的锁会更加不堪重负；另外，使用数据库做分布式锁，当抢到锁的机器挂掉的话如何释放锁也是个头疼的问题。
接下来看下使用ZK如何实现排他锁。排他锁的核心是如何保证当前有且只有一个事务获得锁，并且锁被释放后所有等待获取锁的事务能够被通知到。
和Master选举类似，在需要获取排他锁时，所有客户端都会试图在/exclusive_lock下创建临时子节点/exclusive_lock/lock，最终只有一个客户端能创建成功，该客户端就获取到了锁。同时没有获取到锁的客户端需要到/exclusive_lock节点上注册一个子节点变更的Watcher监听，用于实时监听lock节点的变更情况。
/exclusive_lock/lock是一个临时节点，在一下两种情况下都有可能释放锁：
- 当获取锁的客户端挂掉，ZK上的该节点会被删除
- 正常执行完业务逻辑之后客户端会主动将自己创建的临时节点删除。
无论在什么情况下删除了lock临时节点ZK都会通知在/exclusive_lock节点上注册了子节点变更Watcher监听的客户端，重新发起锁的获取。
感兴趣可以看看：
