Zookeeper（一）

数据模型

类似目录树结构 zookeeper 和目录树 区别就是 文件目录中不能存放数据只能在文件中存放 而zookeeper在目录中也可以存放数据信息

节点中存放的数据有

标题	desc
cZxid	创建节点的事务id
ctime	创建节点的时间
mtime	最后一次节点修改的时间
mZxid	最后一次修改节点的事务id
cversion	子节点被修改的版本号
dataVersion	数据节点的版本号
aclVersion	acl的本版号
ephemeralOwner	是否为临时节点 session节点
dataLength	数据的长度
numChildren	子节点的数量
data	用户自己放入数据内容

四大特性

原子性

ZNode（节点数据操作）所有的节点的写操作都是转发到leader去写的，读操作都是通过访问节点去读取的 也可以采用同步主节点的方式读取 ZNode 中所有的读写操作都是原子性的 只有成功或者失败 没有中间结果

顺序一致性

Zookeeper的客户端发送过来的写入操作 都会通过改变事物ID的方式写入 zookeeper是保证按照客户端发送指令的顺序执行的

数据一致性

Zookeeper 采用的是过半写入机制

一半的服务是强一致性 另外的服务器是采用最终数据一致性

比如5台服务器 3台服务器是强一致性写入操作，2台服务器是最终一致

客户端无论访问节点中任意一台服务，获取的结果都是一致的 因为zookeeper提供了Sync的机制可以选择从leader同步最新数据

可靠性

Zookeeper中当Leader节点崩溃的时候 会触发重新投票选主 这中间Looking状态的时候 是不对外提供服务，但是Zookeeper官方压测结果表明 选举过程一般不会超过200ms 所以中间可能会存在短暂的时间恢复过程。

但是当过半的服务都崩溃后 zookeeper是无法选主 这个时候也就不会对外提供服务了

节点

访问控制

ZNode 中维护一套数据结构 其中ACL 是用于访问控制，用户限制用户可以访问操作的节点 ACL有三个方面控制 Schema 和 User 以及 具体的操作权限

schema:id:permission

操作权限	描述	ACL简写
CREATE	创建节点权限	c
DELETE	删除节点权限	d
READ	读取节点权限	r
WRITE	可以修改节点数据	w
ADMIN	管理员权限	a

持久节点

默认创建的节点都是持久节点 持久节点的意思是 客户端创建节点后 断开关闭 持久节点也会一直在zookeeper服务器中 除非主动删除 否者持久节点则一直存在

时间节点

3.6.0添加的TTL时间节点 TTL 节点必须通过系统属性启用，因为默认情况下它们是禁用的 zookeeper.emulate353TTLNodes 具体查看Zookeeper管理员手册 当最后一次修改的时间 超过了设置TTL的时间的时候 并且没有子节点的时候会删除时间及诶按

临时节点

临时节点是跟客户端的连接的SessionId保持状态一致的关系，当客户端断开连接或者主动删除节点的时候 节点才会被移除 ephemeral标识的节点为临时节点 在节点数据中有字段 ephemeralOwner 标识对应连接的客户端

临时节点不准许拥有子节点 所以临时节点无法创建子节点

容器节点

某一个节点下所有的子节点都被删除后，zookeeper会在某一个时间点删除容器节点

序列节点

znode 会在创建节点的时候在加点名称上添加一个递增的数字 ，一般可用于分布式锁 公平锁 或者队列的实现

选举方式

第一次启动

只要启动达到了过半台数 就会选出leader 选择服务ID最大的
比如有5台服务器 依次启动 1 2 3 4 5 
那么在启动第三台的时候就已经能确认过半了 那么第三台就会被设置为Leader

异常恢复

如果是因为上一个Leader挂了或者重启集群:

1. 所有子节点给出自己的zxid 优先选择最大的事务Id
2. 事务id 都一致，查看谁服务ID最大

比如有 5台服务器 那么每一个连接都有4个连接这4个连接是要么主动连接 要么被连接 总之会保证和其他所有节点建立通讯 此时假设节点3为主节点

1. 从节点感知到主节点挂了 会给其他所有节点发送 自己的 zxid 以及 myid

2. 从节点接收到其他从节点发送过来的zxid 和 myid 进行比较 比较规则

   1.先比较Zxid 优先最大的做为Leader
   2.如果Zxid相同 在比较对应mid 优先最大的做为Leader
   3.最终Leader会将Zxid中高32位 也就是epoch+1 代表Leader的周期
   

3. 将自己比较的结果再次发送给其他的服务器 简称投票

4. 每个服务器内部都会选出最适合的Leader 比如总共有5台服务器 谁的投票数超过3台 直接升级为Leader

PAXOS

PAXOS 具体了解

PAXOS中分为几个角色

1. Proposer 提议发起者

2. Acceptor 提议接收者

3. Learner 提议学习者 不参与决策

   简单理解就是 
   1.Proposer发起提议 所有Acceptor都接收提议，
   2.Acceptor投票处理提议，
   3.如果超过半数Acceptor都通过提议，那么就将提议写入 然后通知给所有Learner
   

Zookeeper中分为

1. Follower 跟随者(从)
2. Leader 领导者(主)
3. Observer 观察者

Zookeeper实现是采用PAXOS这一套思想去设计的

ZAB协议

Zab协议 借鉴了Paxos算法部分思想 是为分布式协调服务Zookeeper专门设计的一种 崩溃后快速恢复 的 原子广播协议 保证数据一致性的核心算法

Leader选举：

   在Zookeeper分布式集群中 Zookeeper自备自动选举功能 
   能快速的在一堆服务器中选出Leader的服务器
   支持在leader崩溃后 再次投票选举 通过上面说的选举方式 再次选择Leader 快速恢复使用

数据同步：

  Leader选举成功后会负责将自己所有的数据同步到所有的Follower节点
  实现统一视图 统一数据 
  这提现了CAP中的分区容错性和数据一致性

广播协议：

  Leader在接收到客户端的Proposal时候 会将对应的Proposal广播给所有的Follower节点，
  Follower通过投票的方式来决定是否处理对应的Proposal

Watch

观察某个节点是否发生改变 客户端可以在 znode 上设置监视。当 znode 发生变化时，会触发并移除 watch。当 watch 被触发时，客户端会收到一个数据包，说 znode 已经改变了。如果客户端和 ZooKeeper 服务器之一之间的连接中断，客户端将收到本地通知

状态
1	节点创建
2	节点删除
3	节点中的数据改变
4	子节点改变
5	数据监听删除
6	子节点监听删除

分布式锁 注册中心 配置中心 都是通过Watch 观察者模式 通知到客户端 客户端实现其他对应逻辑