zetcd：脱离ZooKeeper运行ZooKeeper应用程序

zetcd：脱离ZooKeeper运行ZooKeeper应用程序

etcd实例上部署了一个zetcd代理层：

一个简单的zetcd服务器拓扑

那么这个zetcd代理层是做什么的呢？

ZooKeeper接入etcd3

在底层，zetcd将ZooKeeper的数据模型转换为适合的etcd API的数据。对于key的查找，zetcd将ZooKeeper的分级目录转换为etcd的普通二进制keyspace。对于元数据的管理，zetcd利用事务内存安全地和原子地将ZooKeeper znode信息更新到etcd后端。

ZooKeeper是按目录列出所有的key（getChildren），而etcd是按区间（Range）列出所有的key。下图说明了zetcd是如何在etcd中对key进行编码以便可以快速地列出目录中的key。所有zetcd的key都有一个包括目录深度的前缀（例如，“/”和“/abc/”分别具有0和1的深度）。要列出一个目录，zetcd会给出前缀范围，这个前缀以目录的深度和路径来匹配相应的key（例如，前缀范围[“/zk/key/002/abc/”，“/zk/key/002/abc0”]用于列出/abc/）。这里的目录深度是为了限制目录本身被当作key。如果zetcd将路径当作是没有深度的前缀，那么目录下的所有key，而不是只有其直接子节点，会由etcd返回并被代理抛弃。

etcd内部的ZooKeeper的key层次结构

每个ZooKeeper的key都在ZNode中携带了包含其修改记录、版本、权限的元数据。虽然etcd也包含了每个key的元数据，但却比ZNode中的简单：没有子版本，因为没有目录；没有ACL，因为etcd使用基于角色的身份验证方式；没有时间戳，因为实时时钟在etcd的作用范围之外。这个额外的元数据映射到一组描述了完整的ZNode的key上（见上图）。如果要调整元数据，zetcd会利用软件事务内存原子地更新key的子集，这样就能保持ZNodes的一致性，而不需要昂贵的加锁解锁开销。

此外，zetcd可以对真实的ZooKeeper服务器动态验证它的行为。作为比较，zetcd同时连接到etcd和外部ZooKeeper服务器。当客户端在此模式下向zetcd发出请求时，请求会同时分发到zetcd和ZooKeeper服务器。如果两个服务器的响应在语义上不一致，那么zetcd会通过交叉检查警告对响应进行标记。

转载于：http://geek.csdn.net/news/detail/199488