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
问题
- 创建有序节点，如何获取数据呢？
创建的时候会返回node的name，getData的时候直接拼接path。
-
客户端添加watch只能响应一次，那么配置中心怎么实现的每次都能监听到数据改变？
-
客户端创建连接是根据负载均衡随机连接集群的一个server，那么状态更改的过程是什么？
客户端向连接的server提交状态更改，然后转发给leader节点处理。
