概述
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务和命名服务等。
ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。
ZooKeeper包含一个简单的原语集,提供了java、C和python的接口
ZooKeeper代码版本中，提供了分布式独享锁、选举、队列的接口，代码在src\recipes。其中分布锁和队列有Java和C两个版本，选举只有Java版本。
原理
Zookeeper是以Fast-Paxos算法为基础的，Paxos算法存在活锁的问题，即当有多个propose交错提交时，有可能互相排斥导致没有一个proposer能提交成功，而Fast-Paxos做了一些优化，通过选举产生一个leader(领导者)，只有leader才能提交proposer。
Zookeeper的基本运转流程：
1. 每个Server在内存中存储了一份数据；
2. Zookeeper启动时，将从实例中选举一个leader；
3. Leader要具有最高的执行ID，类似root权限，Leader负责处理数据更新等操作；
4. 一个更新操作成功，当且仅当大多数Server在内存中成功修改数据。
为什么使用zookeeper？
- 大部分分布式应用需要一个主控、协调器或控制器来管理物理分布的子进程(如资源、任务分配等)
- 目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制
- 协调程序的反复编写浪费，且难以形成通用、伸缩性好的协调器
- Zookeeper：提供通用的分布式锁服务，用以协调分布式应用
- Keepalived监控节点不好管理
- Keepalive采用优先级监控
- 没有协同工作
- 功能单一
- Keepalive可扩展性差
Zookeeper特性
- Zookeeper是简单的
- Zookeeper是富有表现力的
- Zookeeper具有高可用性
- Zookeeper采用松耦合交互方式
- Zookeeper是一个资源库
Zookeeper优点
| 特点 | 说明 |
|---|---|
| 最终一致性 | 为客户端展示同一个视图 |
| 可靠性 | 如果消息被一台服务器接受，那么它将被所有的服务器接受 |
| 实时性 | Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口 |
| 独立性 | 各个Client之间互不干预 |
| 原子性 | 更新只能成功或失败，没有中间状态 |
| 顺序性 | 所有Server,同一消息发布顺序一致 |
znode
在zookeeper中，znode是一个跟Unix文件系统路劲相似的节点，可以往这个节点存储或获取数据。如果在创建znode时Flag设置为EPHEMERAL(ephemeral短暂的)，那么当创建这个znode的节点和zookeeper失去连接后，这个znode将不再存在在zookeeper里，Zookeeper使用Watcher察觉事件信息。当客户端接收到事件信息，比如连接超时、节点数据改变、子节点改变，可以调用相应的行为来处理数据。
Zookeeper作用
- Hadoop，使用Zookeeper的事件处理确保整个集群只有一个NameNode,存储配置信息等。
- HBase，使用Zookeeper的事件处理确保整个集群只有一个HMaster,察觉HRegionServer联机和宕机，存储访问控制列表等。
例子
假设我们有20个搜索引擎的服务器(每个负责总索引中的一部分搜索任务)和一个总服务器(负责向这20个搜索引擎的服务器发出搜索请求并合并结果集)，一个备用的总服务器(负责当总服务器宕机时替换总服务器)，一个web的cgi(向总服务器发出搜索请求)。搜索引擎的服务器中的15个服务器提供搜索服务，5个服务器正在生成索引。这20个搜索引擎的服务器经常要让正在提供搜索服务的服务器停止提供服务开始生成索引，或生成索引的服务器已经把索引生成完成可以提供搜索服务。
使用zookeeper可以保证总服务器自动感知有多少提供搜索引擎的服务器并向这些服务器发出搜索请求，当总服务宕机时自动启用备用的总服务器。