功能介绍

Zookeeper是一个开源的分布式应用程序协调服务，为分布式应用提供一致性服务的软件。是Hadoop和Hbase的重要组件。提供功能有：配置服务、域名服务、分布式同步、组服务等。

使用Zookeeper使总服务器自动感知有多少可提供服务的子服务器，并向这些子服务器发出服务请求，当总服务器宕机时自动启用备用的总服务器。

工作原理

Zookeeper核心是原子广播，该机制保障了各个Server之间的数据同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，分别是恢复模式和广播模式。

恢复模式：当服务启动或者领导者崩溃后，Zab进入恢复模式，当领导者被选举出来，且大多数Server完成了跟leader之间的状态同步以后，恢复模式就结束了。?

广播模式：一旦leader和多数的follower进行了状态同步之后，他就可以开始广播消息，进入广播模式。这时候当一个Server加入zookeeper服务中，他会在恢复模式下启动，发现leader并和leader进行状态同步。待到同步结束后，他也参与到广播模式中。广播模式需要保证proposal被按顺序处理，采用递增的事务id（zxid）来保证。

Zookeeper是以Fast Paxos算法为基础，通过选举产生一个leader，只有leader才能提交proposer，具体算法参考Fast Paxos。

Zookeeper的运行流程：

1、选举出leader

2、同步数据

3、选举leader过程中算法有很多，但是要达到的选举标准是一致的。

4、leader要具有最高的执行ID，类似root权限

5、集群中大多数的机器得到响应并接受选举出的leader

应用场景

可靠存储，表现为配置管理、名字服务，因为ZK多备份的可靠性强。可以利用回调机制在数据变更时可以进行全体通知。实现简单高效，因此应用最广。

集群管理，利用ZK的通讯与回调机制完成分布式集群的机器状态监视，甚至很多系统中做主从备份时都会在ZK中注册以方便做热备切换。

服务注册发现管理，可靠存储加上通知回调机制其实满足了服务注册发现的最基本需求，某些在本人看起来不那么靠谱的应用场景，居然也在采用ZK实现。大有一统天下之势，所有类似的需求都开始采用ZK方案，比较出名的系统比如国内的Dubbo和国外的Kafka（居然还把ZK用在了负载均衡上面)、jStorm、Heron(twitter)等。

选主服务，选主服务是ZK参考的原始系统Chubby设计出来最初的应用需求，当时是满足BigTable的master选主。ZK最初也是用在HBase里面，而后所有需要选主服务的都在采用。
需要注意的是有时选主服务也视为分布式锁的一种，很容易混淆概念。的确使用ZK来实现选主服务客观上遵循了时间优先原则，但是实际需求并非一定要满足这条，只要保证关键的唯一性就可以了，因此与同步意义上的锁不同。

分布式同步机制，即真正的分布式锁，但是实际应用并不常见。

负载均衡