1.Zookeeper的介绍

        Zookeeper是一个开源的分布式的，为分布式应用提供协调服务的Apache项目。是 Google 的 Chubby 一个开源的实现。它提供了简单原始的功能，分布式应用可以基于它实现更高级的服务，比如分布式同步，配置管理，集群管理，命名管理，队列管理。

        协调服务主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源。

        在这个分布式系统中如何对进程进行调度，我假设在第一台机器上挂载了一个资源，然后这三个物理分布的进程都要竞争这个资源，但我们又不电脑维修网希望他们进行访问，这时候我们就需要一个协调器，来让他们有序的来访问这个资源。这个协调器就是我们经常提到的那个锁，比如说"进程-1"在使用该资源的时候，会先去获得锁，"进程1"获得锁以后会对该资源保持独占，这样其他进程就无法访问该资源，"进程1"用完该资源以后就将锁释放掉，让其他进程来获得锁，那么通过这个锁机制，我们就能保证了分布式系统中多个进程能够有序的访问该临界资源。那么我们把这个分布式环境下的这个锁叫作分布式锁。这个分布式锁也就是我们分布式协调技术实现的核心内容。

2.Zookeeper的工作机制

        Zookeeper从设计模式的角度来理解是一个基于观察者设计模式的分布式服务管理框架，负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生了变化，ZK就负责通知已经在ZK上注册的那些观察者做出相应的响应。

3.Zookeeper的特点

1. Zookeeper是由一个Leader和多个Folloer组成的集群。
2. 集群中只要有半数以上的节点存活，Zookeeper就能正常工作。
3. 全局数据一致性，每个server上保存的数据都一样，客户端无论访问哪个节点，数据都一致。有几个节点就有几个副本。
4. 更新请求顺序进行，来自同一个客户端的更新请求按其发送顺序一次执行。
5. 数据更新的原子性，一次更新要么成功，要么失败。
6. 实时性，在一定时间范围内，客户端能读到最新数据。

4.Zookeeper的数据结构

        Zookeeper数据模型的结构和Unix文件系统非常像，整体上可以看作一棵树，每个节点被称作一个ZNode，每个ZNode默认能存储1M的数据，每个ZNode都可以通过路径唯一标识。

5.Zookeeper的应用场景

统一的配置管理

HDFS的HA机制中，两个namenode的状态互相感知。

Hbase中Hmaster感知regionserver的上下线。

Kafka集群中主从副本的选举。

6.选举机制

1. 半数机制集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。
2. Zookeeper虽然在配置文件中并没有指定Master和Slave。，Zookeeper工作时，是有一个节点为Leader，其他则为Folloer，Leader是通过内部的选举机制临时产生的。
3. 以一个简单的例子来说明整个选举的过程。

假设有五台服务器组成的Zookeeper集群，它们的id从1-5，它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么，如图。

（1）服务器1启动，此时只有它一台服务器启动了，投票先选自己，因为票数没有超过一半，所以与其他节点通信，它发出去的报文没有任何响应，所以它的选举状态一直是LOOKING状态。

（2）服务器2启动，也是投票先选自己，发现自己只有一票，然后它与最开始启动的服务器1进行通信，互相交换自己的选举结果，由于两者都没有历史数据，所以id值较大的服务器2胜出，由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是3)，所以服务器1、2还是继续保持LOOKING状态。

（3）服务器3启动，根据前面的理论分析，服务器3成为服务器1、2、3中的老大，而与上面不同的是，此时有三台服务器选举了它，超过了总票数的一半，所以它成为了这次选举的Leader。

（4）服务器4启动，根据前面的分析，理论上服务器4应该是服务器1、2、3、4中最大的，由于前面已经有半数以上的服务器选举了服务器3，所以它只能接收当小弟的命了。

（5）服务器5启动，同4一样当小弟。