ZooKeeper源码解析(3)-Cluster启动过程解析

ZooKeeper启动时，有两种模式，第一种是单例模式，这也是默认模式，第二种是cluster模式．今天我们就来探究Cluster模式下，ZooKeeper模式是如何启动的．

启动过程

Cluster模式下的入口为org.apache.zookeeper.server.quorum．

那么，Cluster模式下，节点是如何一步步启动起来的呢？

从上面的这幅图片中，我们可以看到，就是调用的QuorumPeerMain的initializeAndRun方法．

我们看一下这个方法的实现．

这里也很容易理解，就是做了这么几件事：

• 解析配置文件
• 启动一个定时器来清理旧数据并且生成快照
• 如果配置文件中并没有指定server，那么就以单例模式启动

如果配置文件没有错误，就调用runFromConfig()方法．

在这个方法中，会创建一个ServerCnxnFactory类的子类的实例，默认是NIOServerCnxnFactory，用于创建NIOServerCnxn．NIOServerCnxn是ServerCnxn的一个子类，ServerCnxn代表客户端和服务器端之间的一个连接．

在创建完NIOServerCnxnFactory并配置完之后，会实例化一个QuorumPeer实例．QuorumPeer内部封装了Leader选举等Zab一致性算法中的内容．

在QuorumPeer的start()方法中，主要做了这么几件事：

• 通过快照以及事务日志恢复这个节点在宕机之前的状态(loadDataBase()方法)
• 启动上面创建的NIOServerCnxnFactory
• 进行Leader选举

那么，通过快照以及事务日志恢复这个节点宕机之前的状态，是如何做的呢？

具体是这么几步:

• 加载SnapShot并且构建DataTree
• 加载Transaction Log
• 将Transaction Log应用到Data Tree
• 提交Transaction Log并且把它们添加到commited log
• 更新latest zxid

当加载SnapShot以及Transaction Log时，就涉及到了SnapShot以及Transaction Log的格式．

关于它们的格式，请参考本系列中的另外两篇文章：

ZooKeeper源码解析(4)-TxnLog文件格式

ZooKeeper源码解析(5)-Snapshot文件的格式

这部分的代码本身也是比较简单的，这里就不深入介绍了．

由于QuorumPeer本身也是一个线程，我们从其run()方法中可以看到，它就是启动了一个死循环，不断检测这个节点的状态，然后根据不同的状态来做不同的事情，这个在后面的文章ZooKeeper源码解析(6)-Zab实现解析中有介绍，这里就不详细说了．

需要注意的是，我们可以看到，如果当前节点处于LOOKING状态，那么会检测一下是否当前节点已经宕机，如果已经宕机了，那么就可以启动一个ReadOnlyZooKeeperServer．这个对于CAP的权衡．

如果当前节点处于LEADING状态，那么会在完成了确定了自己Leader的地位后，就启动一个ZooKeeperServer．ZooKeeperServer中就是一个节点，其中维护了各种数据，比如，和客户端之间连接的Session．

如果你是刚开始读源码，那么可能会对ServerCnxnFactory,ZooKeeperServer,QuorumPeer之间的关系不清楚．

它们之间的关系如下：

调用的时序图如下：

其中ServerCnxnFactory的继承关系如下：

ServerCnxn的继承关系如下：

ZooKeeperServer的继承关系如下：

每个类图中，我都只是列出了少量属性和方法．

总结

总的来说，在启动时，主要是做这么几件事：

• 解析配置文件
• 根据Snapshot和transaction log在内存中构建出数据和元数据
• 创建ServerCnxnFactory
• 启动Leader选举过程
• 根据选举结果切换到相应的状态并进行相应的操作
• 启动一个ZooKeeperServer来接收客户端操作