一、定义

ZooKeeper = 集群协调器

它是分布式系统中“大脑”般的存在，负责维护共享状态、协调节点行为。提供简单、高效、强一致性的服务接口，被广泛应用于 Hadoop、HBase、Kafka 等项目中。

二、术语

1. 角色

Leader：投票发起者，负责处理写请求并同步数据；是集群的主控节点。

Follower：接收客户端请求，参与选举投票，并将结果反馈给 Leader。

Observer：不参与选举投票，仅接收读请求，提升集v群读性能。

Client：请求发出者，连接到任意 Server 获取服务。

2. Znode

是 ZooKeeper 数据模型的基本单位，类似于文件系统中的“文件或目录”。

支持以下类型：

PERSISTENT：持久节点，不会随会话结束而删除

EPHEMERAL：临时节点，客户端断开后自动删除

3. 状态

工作状态：Leader/Follower/Observer 的运行模式

选举状态：在 Leader 崩溃后触发选举流程，直到选出新的 Leader

4. 事务

所有写操作都构成一个事务，具有原子性。每个事务都有一个全局唯一的 zxid由两部分组成：

高32位：epoch

低32位：事务编号

5. 原子广播

使用 Zab 协议，基于 Paxos 算法变种。核心目标：确保所有 Follower 严格按照相同顺序接收到事务更新，从而实现全局一致性。

三、部署

安装方式：与 JDK 类似，解压即可使用。

配置文件：主要配置文件为 zoo.cfg，包含端口、数据目录、集群成员等信息。每台机器需在 dataDir 目录下创建 myid 文件，内容为该节点编号。

启动命令：

zkServer.sh start

四、数据模型

Znode 树结构：类似于文件系统的树形结构，根节点为 /，支持层级路径访问，例如 /config/app1/host。

支持的操作：创建、删除、修改、读取 Znode，设置 Watcher（监听器），当节点变化时通知客户端。

五、工作原理

1. 数据流程：客户端发送请求 → 节点转发 → Leader 处理 → 同步到所有 Follower → 返回响应在，写操作必须获得过半节点确认才成功。

2. 工作流程：正常运行时，Leader 接收写请求，Follower 只读，所有节点通过心跳保持连接，超时则触发选举。

3. 选举流程：当 Leader 宕机或网络分区时，Follower 发起选举，通过比较 zxid 和服务器 ID，选出拥有最高 zxid 的节点作为新 Leader，选举过程快速且可靠，保障服务连续性。

六、功能

ZooKeeper 的典型应用场景包括

配置管理：集中存储和动态更新系统配置

命名服务：为服务提供唯一标识

同步机制：实现分布式锁、计数器、队列等

集群管理：监控节点存活状态，实现故障转移

一、zookeeper简介

1、什么是zookeeper        

zookeeper官网描述“Apache ZooKeeper致力于开发和维护实现高度可靠的分布式协调的开源服务器”。 什么意思呢？就是Apache ZooKeeper的目标是开发和维护开源服务器，这服务器是干什么的呢？是做分布式协调的。这服务器的特点是什么呢？是高度可靠的。由于zookeeper高度可靠，应用界的大佬solr和大数据服务界的大佬Hadoop就是使用zookeeper提供集群管理。

2、zookeeper的三种部署方式

（1）独立部署模式，即部署在单台机器上的一个zookeeper服务，适用于学习、了解zookeeper基础功能。

（2）伪分布模式，即部署在一台机器上的多个（原则上大于3个）zookeeper服务，虚拟分布式的zookeeper集群，适用于学习、开发和测试，不适用生产环境。

（3）全分布式模式（复制模式），即在多台机器上部署zookeeper服务，真正的集群模式，适合于学习、开发和测试，可投入到生产环境中使用。

二、zookeeper术语

1、角色

2、事务 

要想理解啥事务，首先得理解清楚，什么是一致性。

所谓的一致性，实际上就是围绕着“看见”来的。谁能看见？能否看见？什么时候看见？举个例子：淘宝后台卖家，在后台上架一件大促的商品，通过服务器A提交到主数据库，假设刚提交后立马就有用户去通过应用服务器B去从数据库查询该商品，就会出现一个现象，卖家已经更新成功了，然而买家却看不到；而经过一段时间后，主数据库的数据同步到了从数据库，买家就能查到了下。

假设卖家更新成功之后买家立马就能看到卖家的更新，则称为强一致性；  如果卖家更新成功后买家不能看到卖家更新的内容，则称为弱一致性； 而卖家更新成功后，买家经过一段时间最终能看到卖家的更新，则称为最终一致性。

事务=强致性

3、原子广播  

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。

4、节点

（1）Znode有两种类型，短暂的（ephemeral）和持久的（persistent）

（2）Znode的类型在创建时确定并且之后不能再修改

（3）短暂znode的客户端会话结束时，zookeeper会将该短暂znode删除，短暂znode不可以有子节点

（4）持久znode不依赖于客户端会话，只有当客户端明确要删除该持久znode时才会被删除

（5）Znode有四种形式的目录节点

（6）PERSISTENT（持久的）

（7）EPHEMERAL(暂时的)

（8）PERSISTENT_SEQUENTIAL（持久化顺序编号目录节点）

（9）EPHEMERAL_SEQUENTIAL（暂时化顺序编号目录节点）

5、状态

一、数据流程

1.在Client向Follwer发出一个写的请求

2.Follwer把请求发送给Leader

3.Leader接收到以后开始发起投票并通知Follwer进行投票

4.Follwer把投票结果发送给Leader

5.Leader将结果汇总后如果需要写入，则开始写入同时把写入操作通知给Leader，然后commit

6.Follwer把请求结果返回给Client

2、Follower四个功能：

（1）向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）;

（2）接收Leader消息并进行处理;

（3）接收Client的请求，如果为写请求，发送给Leader进行投票;

（4）返回Client结果;

二、zookeeper工作原理

Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的followers支持。

三、zookeeper选举流程

一、保持数据一致性原则

1、在一个分布式数据库系统中，如果各节点的初始状态一致，每个节点都执行相同的操作序列，那么他们最后能得到一个一致的状态。

2、master维护一个全局写队列，所有写操作都必须放入这个队列编号，那么无论我们写多少个节点，只要写操作是按编号来的，就能保证一 致性。

二、 Paxos算法

       Paxos算法通过投票来对写操作进行全局编号，同一时刻，只有一个写操作被批准，同时并发的写操作要去争取选票，只有获得过半数选票的写操作才会被批准，其他的写操作竞争失败只好再发起一轮投票，就这样，在日复一日年复一年的投票中，所有写操作都被严格编号排序。编号严格递增，当一个节点接受了一个 编号为100的写操作，之后又接受到编号为99的写操作，它马上能意识到自己数据不一致了，自动停止对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性。