集群架构

Leader 服务器是整个 ZooKeeper 集群工作机制中的核心，其主要工作有以下两个：

• 事务请求的唯一调度和处理者，保证集群事务处理的顺序性。
• 集群内部各服务器的调度者。

从角色名字上可以看出，Follewer 服务器是 ZooKeeper 集群状态的跟随者，其主要工作有以下三个：

• 处理客户端非事务请求，转发事务请求给 Leader 服务器。
• 参与事务请求 Proposal 的投票。
• 参与 Leader 选举投票。

Observer 充当了一个观察者的角色，在工作原理上基本和 Follower 一致，唯一的区别在于，它不参与任何形式的投票。

• 在 Client 向 Follower 发出一个写请求。
• Follower 把请求转发给 Leader。
• Leader 接收到以后开始发起投票并通知 Follower 进行投票。
• Follower 把投票结果发送给 Leader。
• Leader 将结果汇总后，如果需要写入，则开始写入，同时把写入操作通知给 Follower，然后 commit。
• Follower 把请求结果返回给 Client。

节点组件

• ServerCnxnFactory，ZooKeeper 服务端网络连接工厂。在早期版本中，ZooKeeper 都是自己实现 NIO 框架，从 3.4.0 版本开始，引入了 Netty。可以通过 zookeeper.serverCnxnFactory 来指定使用具体的实现。

• SessionTracker，ZooKeeper 服务端会话管理器。创建时，会初始化 expirationInterval、nextExpirationTime、sessionsWithTimeout（用于保存每个会话的超时时间），同时还会计算出一个初始化的 sessionID。

• RequestProcessor，ZooKeeper 的请求处理方式是典型的责任链模式，在服务端，会有多个请求处理器依次来处理一个客户的请求。在服务器启动的时候，会将这些请求处理器串联起来形成一个请求处理链。

• LearnerCnxAcceptor，Learner 服务器（等于 Follower 服务器）连接请求接收器。负责 Leader 服务器和 Follower 服务器保持连接，以确定集群机器存活情况，并处理连接请求。

• LearnerHandler，Leader 接收来自其他机器的连接创建请求后，会创建一个 LearnerHandler 实例。每个 LearnerHandler 实例都对应了一个 Leader 和 Learner 服务器之间的连接，其负责 Leader 和 Learner 服务器之间几乎所有的消息通信和数据同步。 ZKDatabase，ZooKeeper 内存数据库，负责管理 ZooKeeper 的所有会话记录以及 DataTree 和事务日志的存储。

• FileTxnSnapLog，ZooKeeper 上层服务和底层数据存储之间的对接层，提供了一系列的操作数据文件的接口，包括事务文件和快照数据文件。ZooKeeper 根据 zoo.cfg 文件中解析出的快照数据目录 dataDir 和事务日志目录 dataLogDir 来创建 FileTxnSnapLog。

• LeaderElection，ZooKeeper 会根据 zoo.cfg 中的配置，创建相应的 Leader 选举算法实现。在 ZooKeeper 中，默认提供了三种 Leader 选举算法的实现，分别是 LeaderElection、AuthFastLeaderElection、FastLeaderElection，可以通过配置文件中 electionAlg 属性来指定，分别用 0 ~ 3 来表示。从 3.4.0 版本开始，ZooKeeper 废弃了前两种算法，只支持 FastLeaderEletion 选举算法。