Zookeeper overview
分布式协调服务
分层命名空间
性能
官方压测leader挂掉后 200ms恢复
性能只读 100000/s 只写 10000/s
每一个节点可以存1M数据
不要把zookeeper当作数据库用，没法存储太多数据
实战
每个节点配置文件都要有所有节点地址
初次启动选主 节点ID大小
每一个节点都能存储数据
二进制安全 --- 按约定好的方式存储 解析
cZxid 创建 64位 前32代表leader纪元 后32代表事物id
mZxid 修改
pZxid 树最大id
节点
节点znode数据结构：
Zookeeper stat structure.png
持久节点
临时节点 - session是否存在，session结束就消失 没有持久化 create -e
序列节点 create -s
用途
- 统一配置管理 服务发现 节点-1M数据
- 分布式锁
分组管理 path结构
统一命名 序列
分布式同步 临时节点 -> 分布式锁 ->一个父节点下创建多个临时节点（队列式 事物式 锁？？）
failvoer 容错 / 故障转移
启动客户端，建立一个session，sessionid会同步给其他节点，timeout内发生故障转移，session信息会保存
选主
事物ID 节点ID
2888 leader接收请求、同步数据
3888 选主投票
egrep '(2888|3888)'
集群
既然是zk集群，就有数据一致性的问题
- 扩展性
leader / follower / observer observer不参与选主，越少速度越快，扩展读能力 - 可靠性
快速选主
数据最终一致性 follower 没有leader时服务不可用状态
修改数据 leader写日志 -> 写数据 -> follower 两阶段提交
client可以选择同步sync请求zk节点
paxos 算法
ZAB协议简版实现
zookeeper atomic broadcast
- 怎样做到主从一致性
拜占庭将军问题：
leader选举
选主过程
redis哨兵订阅redis主通道 发现存活（发布订阅机制！！！）
zookeeper中集群节点要在zoo.cfg中手动配置
