ZooKeeper分布式桥梁开发

　　从传统Java Web转入分布式系统应用，再到接触分布式协调框架ZooKeeper，通过痛苦的思维逻辑和理念转变，历经一个月时间，小伙伴们终于把ZooKeeper嵌入到了BoCloud博云的BeyondContainer中，并在其上进行相应功能的开发： 服务注册与发现、 集群管理、 模块的高可用及分布式锁等。

　　在选定ZooKeeper之前，我们对其他的分布式框架也进行了调研和对比，分别 有etcd和consul。对于etcd而言，在原生接口和提供服务方式方面，etcd更适合作为集群配置服务器，用来存储集群中的大量数据，方便的REST接口也可以让集群中的任意一个节点在使用key |value服务时获取方便，然而etcd在监控服务的状态和通知方面比较麻烦；consul方面，是使用Go语言开发的分布式协调，对业务发现的管理提供很好的支持，他的HTTP API也能很好的和不同的语言绑定，但在业务检测方面有一定的延时，不太适合实时响应的情景；并且etcd和consul需要其他组件的配合才能达到ZooKeeper的服务能力，故ZooKeeper则更加的适合于提供分布式协调服务，实现分布式锁模型方面也较为简单方便，并且功能全，社区活跃，用户群体很大，对所有典型的用例都有很好的封装，支持不同语言的绑定，故最终选定ZooKeeper。

　　在产品开发中使用ZooKeeper是一件有趣的事情，下面就让我们来详细扒一扒我们的开发体验吧。

　　一简单介绍

　　先来简单说明下ZooKeeper原理，再来谈谈在产品中的具体使用。ZooKeeper是一个开放源码的分布式应用程序协调服务，由知名互联网公司雅虎创建，是Google Chubby的开源实现。设计目标是为分布式提供一致性服务，其没有直接采用Paxos算法，而是采用了被称为ZAB的一致性协议。 ZooKeeper具有以下几个特征：

　　1、数据模型

　　ZooKeeper使用一个共享的、树形结构的名字空间-数据模型，其由一系列被称为ZNode的的数据节点组成，其层级关系，如文件系统的目录结构一样，结构如下图所示：

　　每个Znode上都会保存自己的数据内容以及属性信息，节点分为持久节点和临时节点，持久节点除非进行删除操作，否则将会一直保存在ZooKeeper上；而临时节点，他的生命周期和客户端会话绑定，一旦会话失效，这个客户端所创建的所有临时节点都会被删除。另外，可以给节点加上一个属性：sequential，节点创建的时候，会自动在节点后面追加一个由父节点维护的自增数字。