分布式协调神器 ZooKeeper 之总体概述

ZooKeeper 最先起源于雅虎研究院的一个研究小组。当时，雅虎内部不少大型系统基本都须要依赖一个相似的系统来进行分布式协调，可是这些系统每每都存在分布式单点问题。因此，雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。

立项初期，考虑到以前内部不少项目都是使用动物的名字来命名的（例如著名的 Pig 项目)，雅虎的工程师但愿给这个项目也取一个动物的名字。当时研究院的首席科学家 RaghuRamakrishnan 开玩笑说：“再这样下去，咱们这儿就变成动物园了！”是否是颇有趣，顺势你们就表示既然已是动物园了，它就叫动物园管理员吧！各个以动物命名的分布式组件放在一块儿，雅虎的整个分布式系统看上去就像一个大型的动物园了，而 ZooKeeper 正好要用来进行分布式环境的协调一一因而，ZooKeeper 的名字也就由此诞生了！

ZooKeeper概述

ZooKeeper 是一种用于分布式应用程序的分布式开源协调服务。它公开了一组简单的原语，分布式应用程序能够构建这些原语，以实现更高级别的服务，以实现同步，配置维护以及组和命名。它被设计为易于编程，并使用在熟悉的文件系统目录树结构以后设计的数据模型。它在Java中运行，而且具备Java和C的绑定。

众所周知，协调服务很难作到。他们特别容易出现诸如竞争条件和死锁等错误。ZooKeeper 背后的动机是减轻分布式应用程序从头开始实施协调服务的责任。

集群模型

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

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

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

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

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

数据结构

树形结构

首先咱们来看上述数据节点示意图，从而对 ZooKeeper 上的数据节点有一个大致上的认识，在 ZooKeeper 中，每个节点都被称为一个 ZNode，全部 ZNode 按层次化机构进行组织，造成一棵树。ZNode 节点路径标识方式和 Unix 文件系统路径很是类似，都是由一系列使用斜杠（/）进行分割的路径表示，开发人员能够向这个节点中写入数据，也能够在节点下面建立子节点。

节点操做流程

1. 在 Client 向 Follower 发出一个写请求。
2. Follower 把请求转发给 Leader。
3. Leader 接收到之后开始发起投票并通知 Follower 进行投票。
4. Follower 把投票结果发送给 Leader。
5. Leader 将结果汇总后，若是须要写入，则开始写入，同时把写入操做通知给 Follower，而后 commit。
6. Follower 把请求结果返回给 Client。

设计目标

1. 顺序一致性，来自任意特定客户端的更新都会按其发送顺序被提交。也就是说，若是一个客户端将 Znode z 的值更新为 a，在以后的操做中，它又将 z 的值更新为 b，则没有客户端可以在看到z的值是b以后再看到值 a（若是没有其余对z的更新）。
2. 原子性，每一个更新要么成功，要么失败。这意味着若是一个更新失败，则不会有客户端会看到这个更新的结果。
3. 单一系统映像，一个客户端不管链接到哪一台服务器，它看到的都是一样的系统视图。这意味着，若是一个客户端在同一个会话中链接到一台新的服务器，它所看到的系统状态不会比 在以前服务器上所看到的更老。当一台服务器出现故障，致使它的一个客户端须要尝试链接集合体中其余的服务器时，全部滞后于故障服务器的服务器都不会接受该 链接请求，除非这些服务器遇上故障服务器。
4. 持久性，一个更新一旦成功，其结果就会持久存在而且不会被撤销。这代表更新不会受到服务器故障的影响。

推荐一个交流学习群：705127209 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

总体架构

• 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 选举算法。