znode data struct for zookeeper

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那样，是一种通用的分布式一致性算法。

基本模式：消息广播、崩溃恢复。