Zookeeper入门教程（四）：走进 Zookeeper 内部

在 Zookeeper 入门教程前三篇已经基本可以使用 Zookeeper 了，本文就带大家进一步走进 Zookeeper，大致了解一下 Zookeeper 是如何运行的。

Zookeeper 两种节点类型

1. 短暂（ephemeral）：客户端和服务器端断开连接后，创建的节点自己删除

2. 持久（persistent）：客户端和服务器端断开连接后，创建的节点不删除

四种形式的目录节点（默认是persistent ）

1. 持久化目录节点（PERSISTENT）：客户端与zookeeper断开连接后，该节点依旧存在

2. 持久化顺序编号目录节点（PERSISTENT_SEQUENTIAL）：客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号

3. 临时目录节点（EPHEMERAL）：客户端与zookeeper断开连接后，该节点被删除

4. 临时顺序编号目录节点（EPHEMERAL_SEQUENTIAL）：客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号

说一下这个”顺序编号目录节点“，在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序。

ZooKeeper的stat结构

ZooKeeper命名空间中的每个znode都有一个与之关联的stat结构，类似于Unix/Linux文件系统中文件的stat结构。 znode的stat结构中的字段显示如下，各自的含义如下：

• cZxid：这是导致创建znode更改的事务ID。

• mZxid：这是最后修改znode更改的事务ID。

• pZxid：这是用于添加或删除子节点的znode更改的事务ID。

• ctime：表示从1970-01-01T00:00:00Z开始以毫秒为单位的znode创建时间。

• mtime：表示从1970-01-01T00:00:00Z开始以毫秒为单位的znode最近修改时间。

• dataVersion：表示对该znode的数据所做的更改次数。

• cversion：这表示对此znode的子节点进行的更改次数。

• aclVersion：表示对此znode的ACL进行更改的次数。

• ephemeralOwner：如果znode是ephemeral类型节点，则这是znode所有者的 session ID。 如果znode不是ephemeral节点，则该字段设置为零。

• dataLength：这是znode数据字段的长度。

• numChildren：这表示znode的子节点的数量。

ZooKeeper的监听器

在前面的章节，我们已经体验了 ZooKeeper 的监听器，是不是很强大，我们看看它内部原理是什么。在 new ZooKeeper 的里面调用了org.apache.zookeeper.ZooKeeper#ZooKeeper(java.lang.String, int, org.apache.zookeeper.Watcher, boolean, org.apache.zookeeper.client.HostProvider, org.apache.zookeeper.client.ZKClientConfig)构造方法，它里又有下面的语句：

cnxn = createConnection(
    connectStringParser.getChrootPath(),
    hostProvider,
    sessionTimeout,
    this,
    watchManager,
    getClientCnxnSocket(),
    canBeReadOnly);
cnxn.start();

所以我们再看看 ClientCnxn 是咋回事，在 new ClientCnxn 的时候调用了这个构造方法：org.apache.zookeeper.ClientCnxn#ClientCnxn(java.lang.String, org.apache.zookeeper.client.HostProvider, int, org.apache.zookeeper.ZooKeeper, org.apache.zookeeper.ClientWatchManager, org.apache.zookeeper.ClientCnxnSocket, long, byte[], boolean)，里面有这几句代码：

sendThread = new SendThread(clientCnxnSocket);
eventThread = new EventThread();

在 org.apache.zookeeper.ClientCnxn#start 中：

sendThread.start();
eventThread.start();

SendThread，EventThread 继承自 org.apache.zookeeper.server.ZooKeeperThread，ZooKeeperThread 有继承自 java.lang.Thread，也就是说它搞出来了两个子线程，一个负责接收一个负责发送。

也就是说当我们注册监听的时候 ZooKeeper 的节点里有个观察者列表，我们就会加进这个列表，当数据发生变化的时候，ZooKeeper 就会通知 EventThread 这个线程，EventThread 再调用回调函数通知我们的程序。

Zab协议

Zab协议 的全称是 Zookeeper Atomic Broadcast （Zookeeper原子广播）。

Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性。由于是入门教程，我们只简单的说一下，不深入讨论，大家网上一搜一大堆专家。进一步提升可以看下 Paxos 算法，Zab 参考了很多 Paxos，但不完全是哈，Zab 改造了 Paxos。

其实一句话概括Zab协议，就干俩事儿，选举Leader（崩溃恢复模式）、干活儿（消息广播模式）。

Leader选举（崩溃恢复模式）

集群刚刚启动或者 Leader 崩溃了没有 Leader，就会选举 Leader，每个节点会先投自己一票，然后进入looking状态进行观察，看看别人都投给了谁，如果大家都投的是自己那就比较谁牛逼，谁牛逼呢？为了保证分布式系统的时间有序性，因此给每一个事件都分配了一个Zxid，谁拥有最新的Zxid数据版本谁就最牛逼，如果两个人都有最新的Zxid数据版本，那就比编号，谁的大谁牛逼，如果已经有半数的投票结果选出了 Leader，那么后面启动的节点就不会再比较了，直接跟随 Leader 就行了。所以集群要设置成奇数，这样投票才有结果，防止一半一半的尴尬情况。

干活儿（消息广播模式）

当一个客户端 request 请求进入集群以后，这个接收额节点如果不是 Leader，就会把这个请求交给 Leader，Leader 将 request 转化成一个 Proposal（提议）广播给各个节点，每个节点自己有个待写队列 FIFO，然后各个节点根据自身的数据对比事件的 Zxid，比如某个节点记录的 Zxid 是 10，请求写的事件 Zxid 是 9，那我就不同意写入，如果请求是 11 那么就同意写入，这样投票以后返回给 Leader，如果 Leader 若收到半数以上 ACK 反馈为同意写入，那么 Leader 广播给各个节点 commit 提交写入成功。

如果大家都同意写入，只有某个节点不同意写入，那么说明这个节点的数据出问题了，它会自己自杀重新跟 Leader 同步数据，也就保证了集群数据的一致性。

超大规模集群的设想

咱们几台机器投票会很快，但假如集群数量非常庞大达到几万几十万的时候，也去投票吗？很显然不现实，这样写入的效率就太低了，大家光投票就把网络IO资源占完了，所以引入了 观察者 Observer。

观察者 Observer 如同他的名字，只是一个观察者，对leader和follower的工作进行观察监听。方便动态扩展zookeeper集群，而又不影响集群的性能，接收客户端连接，执行leader更新系统状态的命令，不影响集群的性能是因为观察者节点不参与投票，即使是观察者节点宕机了，对集群的运行状态没有影响。