ZooKeeper概述
- ZooKeeper的设计目标
- 简单
- 高可用
- 有序
- 快速
- ZooKeeper的数据模型
- watch：znode数据变化通知
- 为应用提供的保障
- 原语集
- 典型应用
- 配置服务
- leader选举
对于分布式应用的开发，开发者通常需要花费大量的时间和精力解决网络延迟、服务器的不同处理能力、服务器异常重启等带来的问题，除此之外，还要考虑消息如何按序处理、服务器间的资源竞争等，而无法聚焦在具体的应用逻辑上。并且当你耗费大量时间和精力解决这些问题上后，还要面对不同的分布式应用间采用的不同实现导致的管理复杂度上升，难于部署的问题。
ZooKeeper就是为简化分布式系统的构建而诞生的，它最初是Apache Hadoop的子项目，于2010年11月正式成为了Apache的*项目。
ZooKeeper是一个开发源代码的分布式协调服务，提供了一套简单的原语集，具有高性能、高可用的特定，并提供了数据一致性的保障。使用ZooKeeper可以轻松地实现分布式的配置信息维护、统一命名服务、状态同步服务、集群管理等。
ZooKeeper的设计目标
简单
ZooKeeper使用层级的命名空间，整体结构很像一个文件系统，每个节点被称为znode，znode保存对应客户端的数据信息，分布式应用可以很容易的使用该层级结构进行协同合作。并且ZooKeeper会保存一份数据在内存中，以保证高吞吐量和低延迟。
高可用
ZooKeeper支持集群，集群中每个服务器都保存完整的数据信息，集群中的每台服务器都能和其他服务器通讯，只要超过一半的服务器可用，ZooKeeper就能正常运作。
客户端按照随机算法选择连接到集群中的其中一台服务器，如果连接断开，客户端将自动根据随机算法重连到集群中的另一台服务器上，保证服务的连续性。
有序
ZooKeeper的所有更新操作都是按序执行，ZooKeeper将每个更新操作封装为一个事务，并为每个事务分配一个时间戳，根据该时间戳就能判断出事务的先后次序。
快速
ZooKeeper适用于读多写少的场景，ZooKeeper可以通过增加observer来提高读的吞吐量，observer不参与更新的决策过程，因此对系统性能影响较小。当读和写的比例为10:1的场景下，ZooKeeper效率最好。
ZooKeeper的数据模型
ZooKeeper数据模型的结构很像一个真正的文件系统，树上的每个节点成为znode，节点之间用”/”分隔，每个节点使用该节点的路径唯一标识。
每个znode都可以包含数据和孩子节点，客户端可以创建、删除znode，为zonde设置和修改保存的数据，也可以为znode创建孩子节点。但注意ZooKeeper设计的目标不是成为数据库存储或者大数据对象存储，因此每个znode存储的数据大小不应超过1MB。
客户端可以读写znode的数据，读将会获取znode的所有数据，写则是替换znode的整个数据。ZooKeeper使用Access Control List（ACL）对znode做访问控制。
Znode为数据和ACL维护了一个版本号，每次数据和ACL的更新都会导致版本增加，当客户端获取数据时，会同时得到数据的版本信息。
znode可以是一个临时节点，当客户端和服务端的session活跃时，节点则存在，而当session结束，znode将被自动删除。临时节点在一些应用中是非常有用的。
watch：znode数据变化通知
ZooKeeper提供了watch机制，客户端可以设置监听一个znode节点，当znode发生变化时，客户端将收到通知消息。客户端可以根据需要定制不同的监听方式，包括节点的创建、删除，数据变化，以及孩子节点的变化。
为应用提供的保障
ZooKeeper的目标是为更加复杂的分布式应用提供基础服务，它提供了一下保障：
- 客户端提交的更新操作将被按序处理；
- 更新或者成功或者失败，不存在部分成功或部分失败的场景；
- 客户端不论连接任何服务器，都能够看到一样的数据结构；
- 更新操作一旦应用，无论发生任何情况，都保证数据是正确的，不存在更新丢失的场景；
- 保证客户端视图在一个确定的时间内达到最新。
原语集
ZooKeeper的设计目标之一就是简单，因此，ZooKeeper提供了一套简单的API供应用使用，如下：
1. create：在模型树上创建一个节点
2. delete：删除一个节点；
3. exists：判断某个节点是否存在；
4. get data：从某个节点读取数据；
5. set data：设置某个节点的数据；
6. get children：获取某个节点的所有孩子节点；
7. sync：等待数据被传播。
对于API的详细使用方法，参考ZooKeeper 3.5.3-beta API。
典型应用
通过对ZooKeeper中的数据节点的使用，配合watch机制，可以非常方便的构建分布式应用。
配置服务
可以将不同的配置信息放在不同的ZooKeeper的znode上，应用可以根据需要获取对应znode的配置信息，并设置监听，当自己关注的配置信息发生变化后，就会得到通知，并作出处理。
leader选举
在某些分布式应用中，需要一个leader来管理应用服务，当leader由于异常挂掉后，服务就被中断。当集群中的其他主机发觉leader挂掉后，就会重新选举leader提供服务。
使用ZooKeeper的临时节点可以很方便的实现该机制，leader对应一个临时节点，而集群中的其它主机监听该节点变化，当leader挂掉后，所有节点都会受到通知消息，从而发起重新选举leader的操作。