很多负载均衡架构和微服务架构将Zookeeper做为注册中心来使用。今天我们来聊一聊zookeeper的数据结构，看看zookeeper做为注册中心时是怎么保存各个微服务信息的。
zookeeper集群自身维护了一套数据结构。这个存储结构是一个树形结构，其上的每一个节点，我们称之为“znode”。如下所示：
Ø 每一个znode默认能够存储1MB的数据（对于记录状态性质的数据来说，够了）
Ø 可以使用zkCli命令，登录到zookeeper上，并通过ls、create、delete、sync等命令操作这些znode节点
Ø znode除了名称、数据以外，还有一套属性：zxid。这套zid与时间戳对应，记录zid不同的状态（后续我们将用到）
那么每个znode结构又是什么样的呢？如下图所示：
此外，znode还有操作权限。如果我们把以上几类属性细化，又可以得到以下属性的细节：
Ø czxid：创建节点的事务的zxid
Ø mzxid：对znode最近修改的zxid
Ø ctime：以距离时间原点(epoch)的毫秒数表示的znode创建时间
Ø mtime：以距离时间原点(epoch)的毫秒数表示的znode最近修改时间
Ø version：znode数据的修改次数
Ø cversion：znode子节点修改次数
Ø aversion：znode的ACL修改次数
Ø ephemeralOwner：如果znode是临时节点，则指示节点所有者的会话ID；如果不是临时节点，则为零。
Ø dataLength：znode数据长度。
Ø numChildren：znode子节点个数。
znode中的存在类型
我们知道了zookeeper内部维护了一套数据结构：由znode构成的集合，znode的集合又是一个树形结构。每一个znode又有很多属性进行描述。并且znode的存在性还分为四类，如下如所示：
znode是由客户端创建的，它和创建它的客户端的内在联系，决定了它的存在性：
Ø PERSISTENT-持久化节点：创建这个节点的客户端在与zookeeper服务的连接断开后，这个节点也不会被删除（除非您使用API强制删除）。
Ø PERSISTENT_SEQUENTIAL-持久化顺序编号节点：当客户端请求创建这个节点A后，zookeeper会根据parent-znode的zxid状态，为这个A节点编写一个全目录唯一的编号（这个编号只会一直增长）。当客户端与zookeeper服务的连接断开后，这个节点也不会被删除。
Ø EPHEMERAL-临时目录节点：创建这个节点的客户端在与zookeeper服务的连接断开后，这个节点（还有涉及到的子节点）就会被删除。
Ø EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点：当客户端请求创建这个节点A后，zookeeper会根据parent-znode的zxid状态，为这个A节点编写一个全目录唯一的编号（这个编号只会一直增长）。当创建这个节点的客户端与zookeeper服务的连接断开后，这个节点被删除。
另外，无论是EPHEMERAL还是EPHEMERAL_SEQUENTIAL节点类型，在zookeeper的client异常终止后，节点也会被删除。
閱讀更多 HelloWorld應用 的文章
