ZooKeeper--动物管理员
复杂的软件集群系统从来绕不开高可用、负载均衡等问题，大数据系统更是如此。
高可用：计算机系统的可用性定义为系统保持正常运行时间的百分比，具体手段有自动检测，自动切换，自动恢复等。
负载均衡：主要解决单节点数据流量过大、网络负荷过重，一是为了防止单节点负载过大压垮节点导致系统瘫痪，二是益于分摊负载充分挖掘集群潜力。
大数据系统的根本思想在于使用多机器的高并发机器突破单机器算力及存储空间不足的瓶颈，通过水平扩展(分布式)及纵向扩展(微服务拆分)等方式实现集群能力的稳定提升。问题在于当前大数据组件如HDFS、MapReduce等组件均为主从架构，在大数据的场景下主节点的故障转移方案极大影响集群性能，如何提高主节点的可用性、降低众多集群主节点管理复杂性，成为问题的关键。至此，ZooKeeper应运而生。
ZooKeeper在大数据系统中主要用于解决组件主节点的高可用性，如HDFS NameNode依赖ZooKeeper实现故障迁移，同时此类服务与ZooKeeper集群的集成非常简单，仅需在HDFS的配置文件中添加ZooKeeper集群即可。
ZooKeeper是Apache的一个开源分布式协调服务，功能如下：
-
命名服务： 在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务，远程对象等等——这些我们都可以统称他们为名字。其中较为常见的就是一些分布式服务框架（如RPC）中的服务地址列表。
通过在ZooKeepr里创建顺序节点，能够很容易创建一个全局唯一的目录节点，这个目录节点就可以作为一个名字。ZooKeeper 的命名服务即生成全局唯一的ID。
-
配置管理 ：对于分散部署在多台机器上的服务，难以逐个修改配置且易导致问题。将配置信息保存在ZooKeeper的某个目录节点上，所有相关应用程序对此目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到ZooKeeper的通知，从ZooKeeper获取新的配置信息应用到系统中。
-
集群管理：主要管理节点退出和加入，选举Master。
节点退出过程如下，所有节点约定在父目录GroupMembers下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有节点失效，该节点断开与Zookeeper的连接，其创建的临时目录节点被删除，ZooKeeper通知其他节点该节点失效，加入过程类似。
选举Master的过程可简单理解为所有节点在ZooKeeper上创建临时顺序编号目录节点，约定每次选取编号最小的机器作为Master。
-
分布式锁：锁服务可以分为两类，一是独占，二是控制时序。
对于独占锁，可将ZooKeeper上的一个znode看作是一把锁，通过创建znode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。用完删除掉自己创建的distribute_lock 节点就释放出锁。
对于控制时序，可预置目录节点/distribute_lock，所有客户端在它下面创建临时顺序编号目录节点，和选Master一样，编号最小的获得锁，用完删除，依次方便。
-
队列管理：队列的两种类型，一是同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达；二是队列按照 FIFO 方式进行入队和出队操作。
第一类，在约定目录下创建临时目录节点，监听节点数目是否为规定的数目。
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。
上述ZooKeeper的功能均基于ZooKeeper的一致性文件系统和通知机制，那么ZooKeeper的文件系统和通知功能到底是怎样的？
ZooKeeper文件系统
ZooKeeper中每个子目录项如下图命名服务(app1/p_1)都被称作为znode，znode和文件系统一样能够自由的增加、删除，唯一的不同在于znode可以存储数据。
有四种类型的znode：
-
PERSISTENT-持久化目录节点，客户端与ZooKeeper断开连接后，该节点依旧存在；
-
PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点，客户端与zookeeper断开连接后，该节点依旧存在，只是ZooKeeper给该节点名称进行顺序编号 ；
-
EPHEMERAL-临时目录节点，客户端与ZooKeeper断开连接后，该节点被删除 ；
-
EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点，客户端与ZooKeeper断开连接后，该节点被删除，只是ZooKeeper给该节点名称进行顺序编号；
ZooKeeper通知机制
客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，ZooKeeper会通知客户端。
那么ZooKeeper是如何保证文件系统的一致性又怎样设计通知机制？
ZooKeeper分布式集群与数据同步
Zookeeper作为一个集群提供一致的数据服务，需要在节点间同步数据保证一致性。数据同步的好处：
1、容错：一个节点出错，不致于让整个系统停止工作，别的节点可以接管它的工作；
2、提高系统的扩展能力 ：把负载分布到多个节点上，或者增加节点来提高系统的负载能力；
3、提高性能：让客户端本地访问就近的节点，提高用户访问速度。
ZooKeeper通过节点间的数据复制来同步数据，从客户端读写访问的透明度来看，集群进行数据同步有下面两种方式：
1、写主(WriteMaster) ：对数据的修改提交给指定的节点。读无此限制，可以读取任何一个节点。这种情况下客户端需要对读与写进行区别，俗称读写分离。
2、写任意(Write Any)：对数据的修改可提交给任意的节点，跟读一样。这种情况下，客户端对集群节点的角色与变化透明。
ZooKeeper采用的方式是写任意。通过增加机器，它的读吞吐能力和响应能力扩展性非常好，而写，随着机器的增多吞吐能力肯定下降（这也是它建立Observer的原因），而响应能力则取决于具体实现方式，是延迟复制保持最终一致性，还是立即复制快速响应。
ZooKeeper的设计目的
1.最终一致性：Client不论连接到哪个Server，展示给它都是同一个视图，这是ZooKeeper最重要的性能。
2.可靠性：具有简单、健壮、良好的性能，如果消息被到一台服务器接受，那么它将被所有的服务器接受。
3.实时性：ZooKeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，ZooKeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。
4.等待无关（wait-free）：慢的或者失效的Client不得干预快速的Client的请求，使得每个Client都能有效的等待。
5.原子性：更新只能成功或者失败，没有中间状态。
6.顺序性：包括全局有序和偏序两种：全局有序是指如果在一台服务器上消息a在消息b前发布，则在所有Server上消息a都将在消息b前被发布；偏序是指如果一个消息b在消息a后被同一个发送者发布，a必将排在b前面。
如何实现上述设计目的，下面详解ZooKeeper工作原理。
ZooKeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
为了保证事务的顺序一致性，ZooKeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
ZooKeeper的Server有三种状态：
LOOKING：当前Server不知道leader是谁，正在搜寻；
LEADING：当前Server即为选举出来的leader；
FOLLOWING：leader已经选举出来，当前Server与之同步。
ZooKeeper通过选主机制确认Server的工作状态：
当leader崩溃或者leader失去大多数的follower，这时候ZooKeeper进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的Server都恢复到一个正确的状态。ZooKeeper的选举算法有两种：一种是基于basic paxos实现的，另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。
ZooKeeper选主流程(basic paxos)
1.选举线程由当前Server发起选举的线程担任，其主要功能是对投票结果进行统计，并选出推荐的Server；
2.选举线程首先向所有Server发起一次询问(包括自己)；
3.选举线程收到回复后，验证是否是自己发起的询问(验证zxid是否一致)，然后获取对方的id(myid)，并存储到当前询问对象列表中，最后获取对方提议的leader相关信息(id,zxid)，并将这些信息存储到当次选举的投票记录表中；
4.收到所有Server回复以后，就计算出zxid最大的那个Server，并将这个Server相关信息设置成下一次要投票的Server；
5.线程将当前zxid最大的Server设置为当前Server要推荐的Leader，如果此时获胜的Server获得n/2 + 1的Server票数，设置当前推荐的Leader为获胜的Server，将根据获胜的Server相关信息设置自己的状态，否则，继续这个过程，直到Leader被选举出来。 通过流程分析我们可以得出：要使Leader获得多数Server的支持，则Server总数必须是奇数2n+1，且存活的Server的数目不得少于n+1. 每个Server启动后都会重复以上流程。在恢复模式下，如果是刚从崩溃状态恢复的或者刚启动的Server还会从磁盘快照中恢复数据和会话信息，ZooKeeper会记录事务日志并定期进行快照，方便在恢复时进行状态恢复。
ZooKeeper选主流程（fast paxos）
fast paxos流程是在选举过程中，某Server首先向所有Server提议自己要成为leader，当其它Server收到提议以后，解决epoch和 zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复这个流程，最后一定能选举出Leader。
ZooKeeper数据同步流程
选完Leader以后，ZooKeeper就进入状态同步过程。
1. Leader等待Server连接；
2 .Follower连接Leader，将最大的zxid发送给Leader；
3 .Leader根据follower的zxid确定同步点；
4 .完成同步后通知Follower已经成为uptodate状态；
5 .Follower收到uptodate消息后，又可以重新接受Client的请求进行服务了。
ZooKeeper集群不同角色工作任务：
Leader：
1 .恢复数据；
2 .维持与Learner的心跳，接收Learner请求并判断Learner的请求消息类型；
3 .Learner的消息类型主要有PING消息、REQUEST消息、ACK消息、REVALIDATE消息，根据不同的消息类型，进行不同的处理。
PING 消息是指Learner的心跳信息；
REQUEST消息是Follower发送的提议信息，包括写请求及同步请求；
ACK消息是 Follower的对提议的回复，超过半数的Follower通过，则commit该提议；
REVALIDATE消息是用来延长SESSION有效时间。
Follower：
1.向Leader发送请求（PING消息、REQUEST消息、ACK消息、REVALIDATE消息）；
2.接收Leader消息并进行处理；
3.接收Client的请求，如果为写请求，发送给Leader进行投票；
4.返回Client结果。
Follower的消息循环处理如下几种来自Leader的消息：
1 .PING消息： 心跳消息；
2 .PROPOSAL消息：Leader发起的提案，要求Follower投票；
3 .COMMIT消息：服务器端最新一次提案的信息；
4 .UPTODATE消息：表明同步完成；
5 .REVALIDATE消息：根据Leader的REVALIDATE结果，关闭待revalidate的session还是允许其接受消息；
6 .SYNC消息：返回SYNC结果到客户端，这个消息最初由客户端发起，用来强制得到最新的更新。
ZooKeeper集群搭建非常简单，大体分为以下三步，详情百度：
-
准备环境：ZooKeeper本身是由Java语言开发的一个相对独立的基础分布式组件，因此，ZooKeeper的安装除了需要安装JVM外，不再需要依赖其它环境。
-
创建必要目录与文件：ZooKeeper集群中，每一个节点都需创建data目录、dataLog目录以及myid文件（myid文件需创建在data目录下，其值为后续zoo.cfg中配置的第几号服务器，不同节点的myid不同。）
-
配置zoo.cfg ：在ZooKeeper解压包下的conf目录下，有一个示例配置文件zoo_sample.cfg，复制并重命名为zoo.cfg，并在zoo.cfg文件中添加集群的相关配置信息。示例如下：
最后启动服务即可。
