zookeeper

数据结构

ZooKeeper数据模型的结构与Unix文件系统很类似，整体上可以看作是一棵树，每个节点称做一个ZNode。每一个ZNode默认能够存储1MB的数据，每个ZNode都可以通过其路径唯一标识。

应用场景

统一命名服务

统一配置管理

统一集群管理

服务动态上下线

选举机制

SID:服务器ID。用来唯一标识一台ZooKeeper集群中的机器，每台机器不能重复，和myid一致。

ZXID:事务ID。 ZXID是一个事务ID,用来标识一次服务器状态的变更。在某一时刻，集群中的每台机器的ZXID值不一 定完全一致，这和ZooKeeper服务器对于客户端“更新请求”的处理逻辑有关。每次写操作都有事务id (zxid)

Epoch: 每个Leader任期的代号。没有Leader时同一轮 投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加

第一次启动

非第一次启动

节点信息

get -s /

(1) czxid: 创建节点的事务zxid

每次修改ZooKeeper状态都会产生一个ZooKeeper事务ID.事务ID是ZooKeeper中所有修改总的次序。每次修改都有唯一 的zxid, 如果zxid1小于zxid2， 那么zxid1在zxid2之前发生。

(2) ctime: znode 被创建的毫秒数(从1970年开始)

(3) mzxid: znode 最后更新的事务zxid

(4) mtime: znode 最后修改的毫秒数(从1970年开始)

(5) pZxid: znode 最后更新的子节点zxid

(6) cversion: znode 子节点变化号，znode子节点修改次数

(7) dataversion: znode 数据变化号

(8) aclVersion: znode. 访问控制列表的变化号

(9) ephemeralOwner:如果是临时节点，这个是zhode拥有者的session id。如果不是时节点则是0。

(10) datal ength: znode的数据长度

(11) numChildren: znode子节点数量

节点类型（持久/短暂/有序号/无序号）

持久(Persistent) :客户端和服务器端断开连接后，创建的节点不删除.

短暂(Ephemeral) :客户端和服务器端断开连接后，创建的节点自己删除

说明:创建znode时 设置顺序标识，znode名称后会附加一个值，顺序号是一个单调递增的计数器，由父节点维护

注意:在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序

监听器原理

注意:注册一次，只能监听一次。想再次监听，需要再次注册。

写数据原理

应用场景

服务器动态上下线

分布式锁

生产集群按照多少台zk合适？

源码分析

拜占庭将军问题

paxos算法

解决什么问题

算法描述

算法流程

造成这种情况的原因是系统中有一个以上的Proposer,多个Proposers相互争夺Acceptor,造成迟迟无法达成一致的情况。针对这种情况，一种改进的Paxos算法被提出:从系统中选出一个节点作为Leader, 只有Leader能够发起提案。这样，一次Paxos流程中只有一个Proposer不会出现活锁的情况，此时只会出现例子中第一种情况。

zab协议

什么是ZAB算法

Zab借鉴了Paxos算法，是特别为Zookeeper设计的支持崩溃恢复的原子广播协议。基于该协议，Zookeeper设计为只有一台客户端(Leader) 负责处理外部的写事务请求，然后Leader客户端将数据同步到其他Follower 节点。即Zookeeper只有一个Leader 可以发起提案。

Zab协议内容

Zab协议包括两种基本的模式:消息广播、蒯溃恢复。

消息广播

崩溃恢复

cap理论

持久化源码

序列化源码

参考https://www.bilibili.com/video/BV1to4y1C7gw