概念架构图数据模型和分层命名空间特性节点集群paxosZAB 协议watch分布式锁
概念分布式应用程序的分布式协调服务。基于公开的简单原语可以实现更高级别的同步、配置维护、组和命名服务。
架构图
一主多从，更新数据首先更新到主节点，在同步到从节点，可在任意节点读取数据
ZooKeeper 提供的命名空间很像标准文件系统。名称由斜杆（/）分隔的一系列路径元素，每个节点都由路径标识。与为存储而设计的典型文件系统不同，ZooKeeper数据保存在内存中
顺序一致性 - 来自客户端的更新将按照它们的顺序应用原子性 - 更新成功或者失败。没有部分结果。统一视图 - 无论客户端连接到哪个服务器，都将看到相同的视图可靠性 - 应用一旦更新，它将持续到客户端覆盖更新及时性 - 系统的客户视图保证在一定时间范围是最新的 节点
持久节点（有序、无序）临时节点（有序、无序）节点存储
Zxid(64位) = epoch（32位） + 事务ID（32位）
cZxid -> 创建的IDmZxid -> 修改的ID
PZxid -> 当前目录下最大的创建ID
ephemeralOwner -> 临时节点下存储的session
集群
集群搭建
service.id（myid） = ip：port（通信端口）：port（选举端口）集群角色
leader 处理事务请求
follower 处理读请求，转发事物请求，参与选举投票
observice 不参与选举投票的follower，协助follower处理更多的客户端请求集群事务
基于改进版的2PC，半数通过则提交
paxos
基于消息传递的一致性算法
paxos解析
Zookeeper专门设计的一种支持崩溃恢复的原子广播协议
崩溃恢复模式 - 选举Leader + 恢复数据
照成原因
（1）leader 失去过半节点的联系
（2）leader 挂了
投票机制
每次投票传入（myid，zxid，epoch）
myid 服务器id
Zxid(64位) = epoch（32位） + 事务ID（32位）
epoch 朝代，每次选举后 + 1
（1）优先检查zxid，越大优先为leader
（2）zxid相同，比较myid大小，越大优先为leader
消息广播模式 - 数据同步
2pc + 队列 + 多数成功
watch客户端先向Zookeeper服务端成功注册想要监听的节点状态，同时客户端本地会存储该监听器相关的信息在WatchManager中，当Zookeeper服务端监听的数据状态发生变化时，Zookeeper就会主动通知发送相应事件信息给相关会话客户端，客户端就会在本地响应式的回调相关Watch的Handler。
临时顺序节点 + watch，最小的获取锁，后面的节点watch前一个节点，一旦最小的释放了锁，只给第二个节点发事件回调
官方网站
漫画：如何用Zookeeper实现分布式锁？
漫画：什么是ZooKeeper？
思维导图地址
