ZooKeeper 最早起源于雅虎研究院的一个研究小组。当时，雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调，但是这些系统往往都存在分布式单点问题。所以，雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架，以便让开发人员将精力集中在处理业务逻辑上。
立项初期，考虑到之前内部很多项目都是使用动物的名字来命名的（例如著名的 Pig 项目)，雅虎的工程师希望给这个项目也取一个动物的名字。当时研究院的首席科学家 RaghuRamakrishnan 开玩笑说：“再这样下去，我们这儿就变成动物园了！”是不是很有趣，顺势大家就表示既然已经是动物园了，它就叫动物园管理员吧！各个以动物命名的分布式组件放在一起，雅虎的整个分布式系统看上去就像一个大型的动物园了，而 ZooKeeper 正好要用来进行分布式环境的协调一一于是，ZooKeeper 的名字也就由此诞生了！
ZooKeeper 概述
ZooKeeper 是一种用于分布式应用程序的分布式开源协调服务。它公开了一组简单的原语，分布式应用程序可以构建这些原语，以实现更高级别的服务，以实现同步，配置维护以及组和命名。它被设计为易于编程，并使用在熟悉的文件系统目录树结构之后设计的数据模型。它在 Java 中运行，并且具有 Java 和 C 的绑定。
众所周知，协调服务很难做到。他们特别容易出现诸如竞争条件和死锁等错误。ZooKeeper 背后的动机是减轻分布式应用程序从头开始实施协调服务的责任。
集群模型
Leader 服务器是整个 ZooKeeper 集群工作机制中的核心，其主要工作有以下两个：
事务请求的唯一调度和处理者，保证集群事务处理的顺序性。
集群内部各服务器的调度者。
从角色名字上可以看出，Follewer 服务器是 ZooKeeper 集群状态的跟随者，其主要工作有以下三个：
处理客户端非事务请求，转发事务请求给 Leader 服务器。
参与事务请求 Proposal 的投票。
参与 Leader 选举投票。
Observer 充当了一个观察者的角色，在工作原理上基本和 Follower 一致，唯一的区别在于，它不参与任何形式的投票。
数据结构
树形结构
首先我们来看上述数据节点示意图，从而对 ZooKeeper 上的数据节点有一个大体上的认识，在 ZooKeeper 中，每一个节点都被称为一个 ZNode，所有 ZNode 按层次化机构进行组织，形成一棵树。ZNode 节点路径标识方式和 Unix 文件系统路径非常相似，都是由一系列使用斜杠（/）进行分割的路径表示，开发人员可以向这个节点中写入数据，也可以在节点下面创建子节点。
节点操作流程
在 Client 向 Follower 发出一个写请求。
Follower 把请求转发给 Leader。
Leader 接收到以后开始发起投票并通知 Follower 进行投票。
Follower 把投票结果发送给 Leader。
Leader 将结果汇总后，如果需要写入，则开始写入，同时把写入操作通知给 Follower，然后 commit。
Follower 把请求结果返回给 Client。
设计目标
顺序一致性，来自任意特定客户端的更新都会按其发送顺序被提交。也就是说，如果一个客户端将 Znode z 的值更新为 a，在之后的操作中，它又将 z 的值更新为 b，则没有客户端能够在看到 z 的值是 b 之后再看到值 a（如果没有其他对 z 的更新）。
原子性，每个更新要么成功，要么失败。这意味着如果一个更新失败，则不会有客户端会看到这个更新的结果。
单一系统映像，一个客户端无论连接到哪一台服务器，它看到的都是同样的系统视图。这意味着，如果一个客户端在同一个会话中连接到一台新的服务器，它所看到的系统状态不会比 在之前服务器上所看到的更老。当一台服务器出现故障，导致它的一个客户端需要尝试连接集合体中其他的服务器时，所有滞后于故障服务器的服务器都不会接受该 连接请求，除非这些服务器赶上故障服务器。
持久性，一个更新一旦成功，其结果就会持久存在并且不会被撤销。这表明更新不会受到服务器故障的影响。
整体架构
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 选举算法。
原文链接：
http://rdc.hundsun.com/portal/article/952.html
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论