共计 3180 个字符，预计需要花费 8 分钟才能阅读完成。
前 言
ZooKeeper 是一个开源的、高可用的、分布式的协调服务，由 Apache 软件基金会保护。它旨在帮忙治理和协调分布式系统和应用程序，提供了一个牢靠的平台，用于解决分布式同步、配置管理和群组服务等工作。ZooKeeper 广泛应用于构建分布式系统，它提供了一个稳固的根底来治理配置、协调节点、实现分布式锁、实现分布式队列等。通过 ZooKeeper，开发人员能够轻松解决分布式系统中的同步和协调问题，使得分布式应用的开发更加简略和牢靠。
01 zookeeper 的特点
1-1 高可用性
ZooKeeper 的设计指标之一是高可用性。它通过复制数据到多个服务器，应用 Quorum 算法来确保数据的一致性。如果局部节点产生故障，依然可能提供可用的服务，放弃零碎的可用性。
1-2 一致性
ZooKeeper 提供强一致性保障。在 ZooKeeper 集群中，大多数节点（法定人数）必须就数据的状态达成一致意见。这样能够确保每个客户端对数据的读取都能取得雷同的最新数据。
1-3 简略数据模型
ZooKeeper 采纳相似文件系统的数据模型，应用树状构造来存储数据。每个节点（Znode）都有一个门路和一个数据负载。这种简略的数据模型使得 ZooKeeper 易于了解和应用。
1-4 事件告诉
ZooKeeper 反对 Watch 机制，客户端能够设置在 Znode 上的察看，以便在 Znode 产生更改时接管告诉。这样能够实现分布式的事件告诉和合作机制，反对事件驱动的利用程序设计。
1-5 程序节点
ZooKeeper 反对程序节点的创立，即创立的节点会主动带有惟一递增的序列号。这个个性可用于实现分布式锁、分布式队列等常见的协调原语。
1-6 原子操作
ZooKeeper 提供原子操作，能够保障简单的多步骤操作在 ZooKeeper 上是原子的。这些原子操作为构建高级别的分布式协调原语提供了反对。
1-7 集群模式
一致性。ZooKeeper 集群中的节点能够动静地退出或来到，使得零碎更加灵便和可扩大。
1-8 长期节点
ZooKeeper 反对长期节点，这些节点的生命周期与客户端会话相关联。当客户端会话完结时，长期节点会被主动删除，这样能够实现临时性的数据和状态治理。
02 zookeeper 架构
下图为 zookeeper 架构的角色分布图：
2-1 Leader：
集群中的一个服务器被选举为 Leader。Leader 负责解决客户端的写申请（例如创立、更新和删除 Znodes）和协调分布式事务。Leader 通过 ZooKeeper 协定来确保写操作在集群中的大多数节点上同步执行，以保持数据的一致性。如果 Leader 服务器产生故障或断开连接，集群会通过选举算法主动抉择新的 Leader。
2-2 Follower
Follower 是集群中的其余服务器，它们听从 Leader 的指令，复制 Leader 上的写操作，以保持数据一致性。Follower 能够解决客户端的读申请，但不能解决写申请。Follower 与 Leader 放弃心跳连贯，以便及时理解 Leader 的状态。
观察者是一种非凡类型的 ZooKeeper 服务器，它不参加 Leader 选举，也不参加写操作的复制。
03 选举机制
集群中在 Zookeeper 运行期间 Leader 和 非 Leader 各司其职，当有非 Leader 服务器宕机或退出不会影响 Leader，然而一旦 Leader 服务器挂了，那么整个 Zookeeper 集群将暂停对外服务，会触发新一轮的选举。
第一次投票每台机器都会将票投给本人。接着每台机器都会将本人的投票发给其余机器，如果发现其余机器的 zxid 比本人大，那么就须要改投票从新投一次。比方 server1 收到了三张票，发现 server2 的 xzid 为 102，pk 一下发现自己输了，前面果决改投票选 server2 为老大。
3-1 Server id(或 sid)：服务器 ID
比方有三台服务器，编号别离是 1,2,3。编号越大在抉择算法中的权重越大，比方初始化启动时就是依据服务器 ID 进行比拟。
3-2 Zxid：事务 ID
服务器中寄存的数据的事务 ID，值越大阐明数据越新，在选举算法中数据越新权重越大。
3-3 Epoch：逻辑时钟
也叫投票的次数，同一轮投票过程中的逻辑时钟值是雷同的，每投完一次票这个数据就会减少。
3-4 Server 状态：选举状态
LOOKING，竞选状态。FOLLOWING，随从状态，同步 leader 状态，参加投票。OBSERVING，察看状态, 同步 leader 状态，不参加投票。LEADING，领导者状态。
04 ZAB 协定
ZAB（Zookeeper Atomic Broadcast）协定是 Zookeeper 外部用于实现分布式一致性的外围协定。它是一个基于原子播送的协定，用于保障 Zookeeper 集群中数据的一致性和可靠性。ZAB 协定是 Zookeeper 的要害个性之一，确保在集群中的各个节点之间维持数据的一致性。
ZAB 协定的特点：
原子播送：ZAB 协定确保事务是原子性播送的，要么所有 Follower 节点都接管到该事务，要么都没有接管到。这样能够保证数据的一致性。
解体复原：ZAB 协定容许集群在局部节点宕机或解体后，从新选举新的 Leader，从而放弃服务的可用性和容错性。
程序性：ZAB 协定保障所有节点依照雷同的程序处理事务，从而保持数据的一致性。
轻量级：ZAB 协定只须要在集群中的多数节点上进行播送和确认，因而具备较低的通信开销。
穿插验证能够帮忙精确地预计模型的性能，从而反对更好的模型抉择和超参数调整，以取得更好的泛化性能。
05 CAP 实践
Zookeeper 是一个分布式协调服务，它次要用于构建分布式系统中的协调和同步机制。而 CAP 实践则是分布式系统实践中的重要概念，它形容了在分布式系统中三个要害属性的衡量：一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）。CAP 实践指出在分布式系统中，无奈同时满足这三个属性，只能抉择其中两个，因为其中任意两个属性之间是存在抵触的。
具体来说，CAP 实践的三个属性解释如下：
5-1 一致性（Consistency）
在分布式系统中，一致性意味着所有节点在同一时刻看到的数据正本是雷同的。即便是在有多个正本的状况下，所有节点也可能看到雷同的数据。
5-2 可用性（Availability）
可用性指的是零碎可能在无限工夫内对申请作出响应，并可能保障服务的可用性，即便在局部节点故障的状况下。
5-3 分区容忍性（Partition Tolerance）
网络中断或节点之间无奈互相通信，零碎依然可能放弃可用性和一致性。在 CAP 实践中，在分布式系统中只能抉择其中两个属性，并且个别状况下抉择分区容忍性是必须的，因为网络分区是不可避免的，特地在大规模的分布式系统中。Zookeeper 在设计时偏向于 CP（一致性和分区容忍性）模型。
它优先保证数据的一致性和分区容忍性，而可用性可能会在某些状况下受到影响。在 Zookeeper 中，当网络分区产生时，集群会尝试维持数据的一致性，但可能会导致一些节点在分区期间临时不可用。这是因为 Zookeeper 为了保持数据的一致性，须要在少数节点上进行写操作确认，如果无奈满足少数节点的写操作，写操作将被阻塞，从而影响可用性。
06 总结
Zookeeper 作为 Hadoop 我的项目中的一个子项目，是 Hadoop 集群治理的一个必不可少的模块，它次要用 来管制集群中的数据，如它治理 Hadoop 集群中的 NameNode，还有 Hbase 中 Master Election、Server 之间状态同步等。
Zoopkeeper 提供了一套很好的分布式集群治理的机制，就是它这种基于档次型的目录树的数据结构，并对树中的节点进行无效治理，从而能够设计出多种多样的分布式的数据管理模型。