znode 节点数据结构
get -s /node_name
节点内容包括两个部分:节点的数据内容和节点的状态信息
quota 数据内容
get /node_name
stat 状态信息
stat /node_name
- cZxid : Create ZXID,表示节点被创建时的事务ID。
- ctime : Create Time,表示节点创建时间。
- mZxid : Modified ZXID,表示节点最后⼀次被修改时的事务ID。
- mtime : Modified Time,表示节点最后⼀次被修改的时间。
- pZxid : 表示该节点的⼦节点列表最后⼀次被修改时的事务 ID。只有⼦节点列表变更才会更新 pZxid,⼦节点内容变更不会更新。
- cversion : 表示⼦节点的版本号。
- dataVersion : 表示内容版本号。
- aclVersion : 标识acl版本
- ephemeralOwner : 表示创建该临时节点时的会话 sessionID,如果是持久性节点那么值为 0
- dataLength : 表示数据⻓度。
- numChildren : 表示直系⼦节点数。
事务ID zxid(ZooKeeper Transaction Id)
每次写操作都会有事务id。具体的id体现在日志和快照的后缀中。
dataLog 编辑日志
- 位于 datalog 目录,里面的文件以
log.
开头,zxid
结尾,如log.200000001
- 通过 zxid,可以确定更新操作的先后顺序。例如,如果 zxid1 小于 zxid2,说明 zxid1 操作先于 zxid2 发生。
- zxid 对于整个 zk 都是唯一的,即使操作的是不同的 znode
快照 snapshot
存放在 data 目录,里面的文件以 snapshot
开头,zxid
结尾,如 snapshot.0
Paxos(帕克索斯)算法
-
由来:拜占庭将军问题。多个分散的将军,互相传消息,决定攻打某一个目标,可能会出现叛徒导致,提前攻击或攻击不同目标等问题。
-
角色:Proposer、Acceptor、Leaners
-
过程
Proposer 发出一次 propose 请求 携带 proposal id====>选我选我
Acceptor 接收到请求,返回 promise ===> 选你选你
Proposer 收到多数 Acceptor 承诺后,发送 Propose 请求(带详细信息)===> 投票了
Acceptor 针对收到的 propose 请求进行 accept 处理 ===> 投了投了
将结果决议传递给所有 Leaners ===> 选完告知我(两耳不闻窗外事)
- 复杂情况
多个Proposer同时竞争,不断提高价码(Proposal id)。中间的 Acceptor 不断摇摆。此时可能会发生死循环。
ZAB 协议 Zookeeper Atomic Broadcast
Zookeeper 是通过 Zab 协议(2888端口)来保证分布式事务的最终一致性。
Zab借鉴了Paxos算法,但又不像Paxos那样,是一种通用的分布式一致性算法。
基本模式:消息广播、崩溃恢复。