ZooKeeper

1 Zookeeper介绍

Zookeeper是一个分布式的协调服务，为分布式应用程序提供synchronization、configuration maintenance、groups和nameing服务。

Zookeeper是一个有众多服务器节点组成的集群，这些节点中有一个主节点（leader），leader是通过leader selection自动地从服务器节点中选举出来。Zookeeper提供了一个类似于标准文件系统目录结构的hierarchal namespace（层次化的命名空间）。如下图所示，hierarchal namespace中的每一个节点都被称为 znode。Znode是组成hierarchal namespace的基本单位。在源码中对应于类DataNode，其维护着节点用户数据、父节点和子节点集合，以及本节点状态。用户可以在 hierarchal namespace中创建znode，将数据保存在znode中，并监听znode的状态变化，Zookeeper会保证client对znode的操作 是顺序一致性。

2 Zookeeper实现分析

Zookeeper服务器节点的实现可以分成两部分：一部分是处理与客户端交互，实现客户端对zookeeper的hierachal namespace的各种操作。另一部分是作为zab算法（paxos算法的zookeeper实现）的参与者（leader、follower、 observer三种角色的其中一种），实现具体的算法逻辑。

在这篇博客里，我们只讨论zookeeper服务器如何实现第一个部分功能。

Zookeeper服务器的hierachal namespace、znode、客户端与服务器连接、以及客户端可以监听服务器的znode状态的watch机制之间的元数据关系如下图所示：

Zookeeper使用Trie树 来实现了hierachal namespace，由PathTrie这个类来完成。为了实现从路径到znode的映射，zookeeper在内存中维护了一个znode的 hashmap，key为znode在hierachal namespace上的路径，value为znode对象，znode在zookeeper源码中由DataNode这个类实现。为了实现client监 听znode的状态变化，zookeeper将与客户端的连接和hierachal namespace的节点路径进行映射，WatchManager这个类就是用于维护这个映射关系的，其中NIOServerCnxn是 zookeeper服务器与client的一个socket连接；为了监听Znode的目录结构的变化和数据变化，zookeeper使用了两个 WatchManager，分别用来监听namespace的目录结构和数据的变化。

所有以上这些关系都封装在DateTree这个类中，DateTree的类图如下所示。

在paxos算法中有三种角色，分别是提案者，接受者和学习者。在zookeeper中有三种类型的节点，分别是leader、follower和 observer三种类型的节点，分别与paxos的三种角色相对应；需要注意的是zookeeper中还有一个learner的概念，这个 learner是paxos中的学习者，leader、follower和observer都是learner（即都是学习者，可以学习提案），但 observer节点除了是learner之外没有其他功能，也就是说observer只能学习已经批准的提案，而不会参与到提案的投票过程中。 observer这个角色的设定是为了保证提案选举的性能不会随着zookeeper集群规模扩大而降低（参与投票的节点越多，每一次投票花费的事件就越 多）。

在zookeeper中用LeaderZooKeeperServer,FollowerZooKeeperServer和

ObserverZooKeeperServer这三个类来实现三种类型的服务器节点。类图如下所示，为了简单起见没有详细给出成员变量和成员函数。

由于Zookeeper的服务器节点有多种类型，不同类型的服务器节点对client发过来的信令都有不同的处理流程，为了实现最大程度上的代码复 用，zookeeper采用了责任链的设计模式来实现各种类型的zookeeper节点。所以在每一个ZookeeperServer上都会维护一个 RequestProcessor责任链，来处理各个节点上的逻辑。

2.1 leaderZookeeperServer

Leader要完成以下几个事情：

1、接收客户端的request请求

2、将会修改同步数据的request请求 转化为proposal，并保存.

3、向所有的follower发送proposal。

4、接收follower的ack。

5、统计收到的ack，如果某一个proposal的ack超过了半数，那么向所有follower发送commit 信令，并向所有observer发送inform信令，执行这个proposal的动作。

6、leader自己执行已经被commit的proposal所对应的操作，并回复结果。

LeaderZookeeperServer的责任链如下面两图所示：

2.2 FollowerZooKeeperServer

Follower：主要负责批准或否决leader提出的proposal。Follower的主要逻辑处理如下：

1、 发现leader。

2、 建立与leader的连接。

3、 向leader注册。(leader activation)

4、 与leader进行同步。

5、 无限循环

---读取从leader处接收到的信令。

---处理从leader处接收到的信令。

A、 如果是PROPOSAL信令（写请求），将此信令投递到FollowerZooKeeperServer的synProcessor。主要作用是回复leader一个ack。

B、 如果是COMMIT信令，将此信令投递到FollowerZooKeeperServer的commitProcessor。最终执行FollowerZooKeeperServer的commit函数。

C、 如果是SYNC信令，将此信令投递到FollowerZooKeeperServer的commitProcessor。commitProcessor直接将此信令转发给FinalRequestProcessor，将sync信令带的内容写入持久层。

FollowZookeeperServer的责任链如下所示：

2.3 ObserverZooKeeperServer

observer：学习已经被commit的proposal的结果，然后执行相应的操作。Observer主要处理逻辑：

1、 发现leader。

2、 连接到leader上，建立TCP连接。

3、 与leader进行同步，同步leader上已经被commit的proposal。

4、 无限循环，读取接收到得信令，处理信令。

1、如果是syn信令，调用ObserverZooKeeperServer的syn函数，投递到commitProcessor中。

2、如果是info信令，同样调用ObserverZooKeeperServer的commit函数，投递到commitProcessor中。

OserverZookeeperServer的责任链基本上与follower的相同如下，只是commitProcessor调用的commit函数里的处理不同：

2.4 Zookeeper各节点交互

Zookeeper各个角色的信令交互图：

最后画了一张各个zookeeper server的信令交互图

http://www.sxt.cn/u/756/blog/5236