get -s /node_name
节点内容包括两个部分：节点的数据内容和节点的状态信息
quota 数据内容get /node_namestat 状态信息
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，如果是持久性节点那么值为 0dataLength : 表示数据⻓度。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 是通过 Zab 协议来保证分布式事务的最终一致性。
Zab借鉴了Paxos算法，但又不像Paxos那样，是一种通用的分布式一致性算法。
基本模式：消息广播、崩溃恢复。
