zookeeper-官方文档笔记

定义

• ZooKeeper是用于维护配置信息，命名，提供分布式同步以及提供组服务的集中式服务。

• ZooKeeper与标准文件系统之间的主要区别在于，每个znode都可以具有与之关联的数据（每个文件也可以是目录，反之亦然），并且znode限于它们可以拥有的数据量（1M）

• 读请求的吞吐量随服务器数量成比例增长，写请求的吞吐量随服务器数量而减小

• 高性能，高可用性，严格有序访问

• 层次空间

  
  
  image.png

一些概念

znode: zk的基础数据单元，对应图中的每一个节点，可以存放数据。
临时节点-随session的生命周期，不能有children节点（不然有可能没法删除）
序列化节点（持久化、临时）
容器节点
TTL节点
stat结构:
czxid: 创建操作标识id
mzxid: 修改
pzxid: 孩子修改操作
cversion（孩子节点修改引起的版本标识）
version(当前节点的版本标识)
aversion(权限控制标识)
ephemeralOwner(临时节点的，sessionId)
dataLength（当前节点的数据大小）
numChildren

chroot

连接的时候即可指定root，case：
zkCli -server 127.0.0.1:2181/zookeeper/onlinle

zk提供的保证（以下五个功能点为维度理解zk）

顺序一致性-来自客户端的更新将按照发送的顺序应用。
原子性-更新成功或失败。没有部分结果。
单个系统映像-无论客户端连接到哪个服务器，客户端都将看到相同的服务视图。
可靠性-应用更新后，此更新将一直持续到客户端覆盖更新为止。
及时性-确保系统的客户视图在特定时间范围内是最新的。

概念&原理

zab协议：zk原子性广播协议

• 保证更改状态有序性
• 领导选举&故障领导者&节点恢复

过程：类似二阶段提交。 leader收到状态更改的事务请求，将改请求send给follwer，follwer将改请求存放到history里面，并向leader发送ack。当受到ack的个数大于法定个数，则发从commit命令，follwer接受commit，follwer执行commit，会先执行commit序列号小的（保证所有的操作按顺序执行）
（ps： 问题： follwer什么时候拒绝发送ack？ leader如何知道commit全部完成 ?）

领导者选举：
0： 潜在领导者选举
1：发现
3：同步
4：广播

简单api

[代码case]
create：在树中的某个位置创建一个节点
delete：删除节点
exists ：测试节点是否存在于某个位置
get data：从节点读取数据
setData：将数据写入节点
getChildren：获取节点子节点的列表
sync：等待数据传播

高级应用

• 配置、命名空间
• Barriers
• Queues
• Locks
• Shared Locks
• Two-phased Commit
• Leader Election

问题

1. 创建有序节点，如何获取数据呢？

创建的时候会返回node的name，getData的时候直接拼接path。

2. 客户端添加watch只能响应一次，那么配置中心怎么实现的每次都能监听到数据改变？

3. 客户端创建连接是根据负载均衡随机连接集群的一个server，那么状态更改的过程是什么？

客户端向连接的server提交状态更改，然后转发给leader节点处理。