ZOOKEEPER 问题集合

WATCHER的事件通知机制是如何实现的

看过Google的分布式锁机制Chubby论文会发现，ZooKeeper中多了一个事件订阅机制：Watcher。那么Watcher内部究竟是如何实现的呢？

其实，在ZooKeeper客户端中，有一个成员变量（ZKWatchManager）专门负责管理所有的Watcher，当用户使用如下代码时：

 

1	List<String> list = zk.getChildren(path, watcher);

 

ZooKeeper会将这个Watcher存储在ZKWatchManager中，同时通知ZooKeeper服务器记录该Client对应的Session中的Path下注册的事件类型。当ZooKeeper服务器发生了指定的事件后，ZooKeeper服务器将通知ZooKeeper客户端，ZooKeeper客户端再从ZKWatchManager中找到对应的回调函数，并予以执行。

整个过程中，客户端存储事件的信息和Watcher的执行逻辑，服务端只存储事件的信息。

 

ZOOKEEPER是否对ZNODE有大小限制

如果你仔细看过ZooKeeper的文档，会发现文档中对ZNode的大小做了限制，最大不能超过1M。

这个1M的大小限制在ZooKeeper的客户端和服务端都有限制：

ZooKeeper确实对数据的大小有限制，默认就是1M，如果希望传输超过1M的数据，可以修改环境变量“jute.maxbuffer”即可。

 

为什么要限制ZOOKEEPER中ZNODE的大小

ZooKeeper是一套高吞吐量的系统，为了提高系统的读取速度，ZooKeeper不允许从文件中读取需要的数据，而是直接从内存中查找。

还句话说，ZooKeeper集群中每一台服务器都包含全量的数据，并且这些数据都会加载到内存中。同时ZNode的数据并支持Append操作，全部都是Replace。

所以从上面分析可以看出，如果ZNode的过大，那么读写某一个ZNode将造成不确定的延时;同时ZNode过大，将过快地耗尽ZooKeeper服务器的内存。这也是为什么ZooKeeper不适合存储大量的数据的原因。

 

如何提升ZOOKEEPER集群的性能

我们说性能，可以从两个方面去考虑：写入的性能与读取的性能。

由于ZooKeeper的写入首先需要通过Leader，然后这个写入的消息需要传播到半数以上的Fellower通过才能完成整个写入。所以整个集群写入的性能无法通过增加服务器的数量达到目的，相反，整个集群中Fellower数量越多，整个集群写入的性能越差。

ZooKeeper集群中的每一台服务器都可以提供数据的读取服务，所以整个集群中服务器的数量越多，读取的性能就越好。但是Fellower增加又会降低整个集群的写入性能。为了避免这个问题，可以将ZooKeeper集群中部分服务器指定为Observer。

 

zookeeper集群中选举中，每个节点都会投票，如果某个节点获得超过半数以上的节点的投票，则该节点就是leader节点了。

 

Zookeeper默认提供了4种选举方式，默认是第4种: FastLeaderElection。

 

我们先假设我们这是一个崭新的集群，崭新的集群的选举和之前运行过一段时间的选举是有稍许不同的，

节点状态： 每个集群中的节点都有一个状态 LOOKING, FOLLOWING, LEADING, OBSERVING。都属于这4种，每个节点启动的时候都是LOOKING状态，如果这个节点参与选举但最后不是leader，则状态是FOLLOWING，如果不参与选举则是OBSERVING，leader的状态是LEADING。

开始这个选举算法前，每个节点都会在zoo.cfg上指定的监听端口启动监听(server.1=127.0.0.1:20881:20882)，这里的20882就是这里用于选举的端口。

 

ZooKeeper的工作原理

在zookeeper的集群中，各个节点共有下面3种角色和4种状态：

• 角色：leader,follower,observer
• 状态：leading,following,observing,looking

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议（ZooKeeper Atomic Broadcast protocol）。Zab协议有两种模式，它们分别是恢复模式（Recovery选主）和广播模式（Broadcast同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。

每个Server在工作过程中有4种状态：

LOOKING：当前Server不知道leader是谁，正在搜寻。

LEADING：当前Server即为选举出来的leader。

FOLLOWING：leader已经选举出来，当前Server与之同步。

OBSERVING：observer的行为在大多数情况下与follower完全一致，但是他们不参加选举和投票，而仅仅接受(observing)选举和投票的结果。

Leader Election

当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。Zk的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。先介绍basic paxos流程：

1.选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；

2.选举线程首先向所有Server发起一次询问（包括自己）；

3.选举线程收到回复后，验证是否是自己发起的询问（验证zxid是否一致），然后获取对方的id（myid），并存储到当前询问对象列表中，最后获取对方提议的leader相关信息（id,zxid），并将这些信息存储到当次选举的投票记录表中；

4.收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server；

5.线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，设置当前推荐的leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到leader被选举出来。

通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1.

每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。

fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。