ZooKeeper的名字空间节点（有关znode的一切）

    上一篇有人跟我说比较深奥和抽象，确实，我写这个不是按照循序渐进的写法写的，而是先写那本OREILLY书最不清楚的部分，然后再写次不清楚的……到最后会覆盖zk的绝大多数特性，这时候会再给出一个阅读次序的建议。

    这篇来说说有关znode的一切，比较容易理解，也很容易通过zkCli.sh来实验。

分层名字空间

    上图是ZooKeeper的分层名字空间的示意图，可见这种结构很像典型的文件系统结构：以/分割各元素的一种路径，ZooKeeper名字空间的每个节点都是以这样一个路径来标识的。这样的节点统一称为znode。

Znode

    然而，ZooKeeper的名字空间和文件系统仍有着显著的差别。文件系统典型地有目录和文件，目录可包含其他目录或文件，文件则实际存储数据。而znode既可以有其他子znode，又可以存放数据（严格说是必须存放数据，真没有的话得给个“”），因此znode可以看做是目录和文件的合体。znode被用来存储Byte级或KB级的数据，如状态信息、配置信息、位置信息等，因此znode可存放数据量的最大值默认被设为1MB，请注意，该值不仅计算数据的Byte数，所有子节点的名字也要折算成Byte数计入，因此znode的子节点数也不是无限的。改大这个参数可以存储更多数据或包含更多子znode，但我非常不建议这样做，因为这与ZooKeeper的设计目的相悖，只有数据足够小，才能保证ZooKeeper的高读取性能。如果要存储大量数据，有的是其他解决方案。

    除了数据外，znode还管理了其他一些元数据，存储在stat对象中：

• 版本号：znode的数据每次更新时，该版本号递增。当客户端请求该znode时，数据和版本号会一起发回。另外，当znode重建时版本号会被重置，这似乎很自然，但很多时候这是巨坑的来源，比如：客户端执行了’set /test “testdata” 1’，即指定版本1写/test节点，之后该znode被删除重建，数据默认置为“”，版本号还是1，此时客户端请求时虽然该版本号仍然存在，但已经是错误的数据了。
• ACL：即Access Control List，用来限定哪些账号可以操作该znode。ZooKeeper内置了4种ACL模式，第1种是any，即不鉴权；第2种是super，即不受任何ACL约束的管理员模式；第3种是digest，使用用户名和密码进行认证；第4种是SASL，通常使用Kerberos协议来认证，但Kerberos也是个大坑，并且对性能也有一定影响。
• 时间戳：其实就是zxid，存储该znode创建或修改时的时间戳，用于缓存验证或协调更新等。

    理解了这些就可以做点操作了，所有zkCli.sh的命令如下，主要掌握ls，get，set，create，delete几个就够玩了（应该明白为何zkCli下没有cd这样的命令）：

ZooKeeper -server host:port cmd args