实现

Zookeeper有两种运行模式：

独立模式（standalone mode):只运行在一台服务器上，适合测试环境

复制模式（replicated mode)：运行于一个集群上，适合生产环境，这个计算机集群被称为一个“集合体”（ensemble）。Zookeeper通过复制来实现高可用性，只要集合体中半数以上的机器处于可用状态，它就能够保证服务继续。为什么一定要超过半数呢？这跟Zookeeper的复制策略有关：zookeeper确保对znode树的每一个修改都会被复制到集合体中超过半数的机器上。

生产环境，zookeeper集群的服务器数目应该是奇数。

Zookeeper集群中的角色及其职责

领导者

　　1.管理写请求

跟随者

　　1.响应客户端的读请求

　　2.负责把客户端提交的写请求转发给领导者

 

znode的观察机制

 

znode以某种方式发生变化时，“观察”（watch）机制可以让客户端得到通知。可以针对ZooKeeper服务的“操作”来设置观察，该服务的其他操作可以触发观察。比如，客户端可以对某个客户端调用exists操作，同时在它上面设置一个观察，如果此时这个znode不存在，则exists返回false，如果一段时间之后，这个znode被其他客户端创建，则这个观察会被触发，之前的那个客户端就会得到通知。

sync： 将客户端的znode视图与ZooKeeper同步

SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。

跨客户端视图的并发一致性：

ZooKeeper并不保证在某时刻，两个不同的客户端具有一致的数据视图。因为网络延迟的原因，一个客户端可能在另一个客户端得到修改通知之前进行更新。假定有两个客户端A和B。如果客户端A将一个节点/a的值从0修改为1，然后通知客户端B读取/a，客户端B读取到的值可能还是0，这取决于它连接到了哪个服务器。如果客户端A和B读取到相同的值很重要，那么客户端B应该在执行读取之前调用sync()方法。

所以，ZooKeeper本身不保证修改在多个服务器间同步地发生，但是可以使用ZooKeeper原语来构建高层功能，提供有用的客户端同步。

 设计目的

1.最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。

2 .可靠性：具有简单、健壮、良好的性能，如果消息m被到一台服务器接受，那么它将被所有的服务器接受。

3 .实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。

4 .等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。

5.原子性：更新只能成功或者失败，没有中间状态。

6 .顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

节点宕机：

应用集群中，我们常常需要让每一个机器知道集群中（或依赖的其他某一个集群）哪些机器是活着的，并且在集群机器因为宕机，网络断链等原因能够不在人工介入的情况下迅速通知到每一个机器。

Zookeeper同样很容易实现这个功能，比如我在zookeeper服务器端有一个znode叫/APP1SERVERS,那么集群中每一个机器启动的时候都去这个节点下创建一个EPHEMERAL类型的节点，比如server1创建/APP1SERVERS/SERVER1(可以使用ip,保证不重复)，server2创建/APP1SERVERS/SERVER2，然后SERVER1和SERVER2都watch /APP1SERVERS这个父节点，那么也就是这个父节点下数据或者子节点变化都会通知对该节点进行watch的客户端。因为EPHEMERAL类型节点有一个很重要的特性，就是客户端和服务器端连接断掉或者session过期就会使节点消失，那么在某一个机器挂掉或者断链的时候，其对应的节点就会消失，然后集群中所有对/APP1SERVERS进行watch的客户端都会收到通知，然后取得最新列表即可。

zookeeper是一个高可用性，高性能的协调服务

解决哪些问题

在分布式应用中，经常会出现部分失败的情况，即当节点间传递消息的时候由于网络或者接收者进程死掉等原因，发送者无法知道接收者是否收到消息。

由于部分失败是分布式系统固有的特征因此zookeeper并不能避免部分失败，但是它可以帮你在部分失败的时候进行正确处理

为了解决这个问题zookeeper具有以下特征：

1：zookeeper提供丰富的构件（building block）来实现很多协调数据结构和协议

2：访问原子性，客户端要么读到所有数据，要么读取失败，不会出现只读取部分的情况

3：zookeeper运行在一组机器上，具有高可用性，帮助系统避免单点故障，同时删掉故障服务器

4：顺序一致性：任意客户端的更新请求会被按照发送顺序提交

5：单一系统映像：当一台服务器故障，导致它的客户端需要连接其它服务器的时候，所有更新晚于故障服务器的服务器都不会接收请求，一直到更新赶上故障服务器

6：及时性：任何客户端能看到的滞后都是有限的，不会超过几十秒，且提供sync操作强制客户端所连的服务器与领导者同步

7：会话：每个客户端连接时会尝试连接到配置列表中的一台服务器，一旦失败会自动连接另一台服务器依次类推，知道成功连接一台服务器，从而创建一个会话，客户端可以位每个会话设置超时时间，一旦会话过期，则所有短暂znode会丢失，因为zookeeper会自动发送心跳包，所以很少发生

8：约会机制（rendezvous），在交互的过程中，被协调的各方不许要事先彼此了解，甚至不必同时存在

9：ACL：zookeeper提供了digest（通过用户名密码），host（通过主机名），ip（通过ip地址）3种身份验证模式，依赖与zookeeper的身份验证机制每个ACL都是一个身份对应一组权限，如果我们要给demo.com的客户端域一个读权限在java语言中可以这样创建：

new ACL(Perms.READ, new Id("host", "demo.com"));

Ids.OPEN_ACL_UNSAFE是将所有ADMIN之外的权限授予每个人

另zookeeper还可以集成第三方的身份验证系统

10：提供关于通用协调模式的开源共享资源库

11：高性能的（官方数据）对以写为主的工作负载来说使用5台不错的机器基准吞吐量达到10000+