Zookeeper简介

1.Zookeeper的介绍

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

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

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

2.Zookeeper的工作机制

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

3.Zookeeper的特点

1. Zookeeper是由一个Leader和多个Follower组成的集群。
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，其他则为Follower，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一样当小弟。