一 简介

1. zookeeper是一个为分布式应用程序提供的一个分布式开源协调服务框架。是Google的Chubby的一个开源实现，是Hadoop和Hbase的重要组件。主要用于解决分布式集群中应用系统的一致性问题。

2. 提供了基于类似Unix系统的目录节点树方式的数据存储。

3. 可用于维护和监控存储的数据的状态的变化，通过监控这些数据状态的变化，从而达到基于数据的集群管理。

比如namenode 启动两个 namenode1 namenode2

4. 提供了一组原语(机器指令)，提供了java和c语言的接口

通俗理解: zk其实是一个小型的文件存储系统,可以放少量数据,不是正儿八经的数据,都是一些关于服务器的小数据。2、它可以感知服务器是否上线，是否掉线。

二 特点

1.集群:  zk是一个leader(领导者) 和 多个 follower(追随者) 组成的集群

2.高可用性: 一个集群中只要有半数以上的节点存活,集群就能正常服务

3.全局数据一致性: 每个server都保存一份相同的数据,client无论连接哪个server,数据都是一样的

4.更新请求顺序进行: 来自同一个client 的请求按照发送顺序依次执行

5.数据更新原子性: 一次数据的更新要么全部成功,要么全部失败

6.数据实时性: 在一定范围内,client能读到最新的数据

三 数据存储形式

从根节点 " / " 开始

每个子节点都可以有其他子节点,也可以在节点上存放数据

四  三个角色

leader 领导者 follower 追随者  observer  观察者

Leader: 

   集群中只有一个Leader(某一时刻)  ,如果leader挂了,集群暂停服务,自动从follower中选举出新的leader

• 处理所有写请求：客户端发起的 create、setData、delete 等写操作，最终都要转发给 Leader 处理。

• 发起投票：收到写请求后，Leader 会生成一个提案（Proposal），广播给所有 Follower 进行投票。

• 决定事务顺序：为每个写请求分配全局唯一的 ZXID（事务ID），保证所有节点的操作顺序一致。

Follower:

• 参与 Leader 选举投票：当 Leader 宕机时，Follower 有投票权，决定谁成为新 Leader。

• 参与事务投票：对 Leader 发起的写提案进行表决（ACK 确认）。

• 处理读请求：可以直接响应客户端的读请求，减轻 Leader 压力。

• 转发写请求：如果收到客户端的写请求，会转发给 Leader。

Follower 的数量建议为奇数,便于投票选举

Follower是集群一致性的核心保障

Observer:

• 处理读请求：和 Follower 一样能直接响应读操作。

• 不参与任何投票：既不能投票选举 Leader，也不对写提案进行 ACK 确认。

• 同步数据：从 Leader 或 Follower 同步数据，但只为了提供读服务。

Observer 不影响写性能: 因为不参与投票,增加Observer 不会拖慢写操作延迟

适合读多写少的场景: 比如配置中心,服务注册中心,大量客户端只读不写时,用观察者水平拓展读能力.

一句话:     Leader 拍板写，Follower 投票定，Observer 旁听读。