ZooKeeper 特点/设计目的

ZooKeeper 作为一个集群提供数据一致的协调服务，自然，最好的方式就是在整个集群中的 各服务节点进行数据的复制和同步。

数据复制的好处

1、容错：一个节点出错，不至于让整个集群无法提供服务

2、扩展性：通过增加服务器节点能提高 ZooKeeper 系统的负载能力，把负载分布到多个节点上

3、高性能：客户端可访问本地 ZooKeeper 节点或者访问就近的节点，依次提高用户的访问速度

设计目的

1、最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的性能。 
2、可靠性：具有简单、健壮、良好的性能，如果消息被到一台服务器接受，那么它将被所有的服务器接受。 
3、实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 
4、等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。 
5、原子性：更新只能成功或者失败，没有中间状态。 
6、顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。

ZooKeeper 典型应用场景

命名服务

　　命名服务是分布式系统中较为常见的一类场景，分布式系统中，被命名的实体通常可以是集 群中的机器、提供的服务地址或远程对象等，通过命名服务，客户端可以根据指定名字来获 取资源的实体、服务地址和提供者的信息。Zookeeper 也可帮助应用系统通过资源引用的方 式来实现对资源的定位和使用，广义上的命名服务的资源定位都不是真正意义上的实体资源， 在分布式环境中，上层应用仅仅需要一个全局唯一的名字。Zookeeper 可以实现一套分布式 全局唯一 ID 的分配机制。

配置管理

　　程序总是需要配置的，如果程序分散部署在多台机器上，要逐个改变配置就变得困难。现在 把这些配置全部放到 ZooKeeper 上去，保存在 ZooKeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 ZooKeeper 的通知，然后从 ZooKeeper 获取新的配置信息应用到系统中就好

集群管理

所谓集群管理无在乎两点：是否有机器退出和加入、选举 master。

　　对于第一点，所有机器约定在父目录 GroupMembers 下创建临时目录节点，然后监听父目录 节点的子节点变化消息。一旦有机器挂掉，该机器与 ZooKeeper 的连接断开，其所创建的 临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知 道：有兄弟挂了。新机器加入也是类似，所有机器收到通知：新兄弟目录加入，又多了个新 兄弟。

　　对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小 的机器作为 master 就好。当然，这只是其中的一种策略而已，选举策略完全可以由管理员 自己制定。

分布式锁

有了 ZooKeeper 的一致性文件系统，锁的问题变得容易。 锁服务可以分为两三类

一个是写锁，对写加锁，保持独占，或者叫做排它锁，独占锁

一个是读锁，对读加锁，可共享访问，释放锁之后才可进行事务操作，也叫共享锁

一个是控制时序，叫时序锁

　　对于第一类，我们将 ZooKeeper 上的一个 znode 看作是一把锁，通过 createznode 的方式来 实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了 这把锁。用完删除掉自己创建的 distribute_lock 节点就释放出锁

　　对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录 节点，和选 master 一样，编号最小的获得锁，用完删除，依次有序

队列管理

　　两种类型的队列：

　　1、同步队列：当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。

　　2、先进先出队列：队列按照 FIFO 方式进行入队和出队操作。

　　第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。

　　第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。 同步队列的流程图：