每次面对一个新的事物，我们首先肯定要问一句，什么是Zookeeper,好，它来了，ZooKeeper是一个分布式的，开源的分布式应用程序协调服务，从设计模式角度来理解的话就是一个基于观察者模式设计的分布式服务管理框架。即管理着一些数据，这些数据发生变化的时候要给观察者提供响应。
它是一个为分布式应用提供一致性服务的软件，提供的功能包括：统一命名服务，统一配置管理，统一 集群管理，服务节点动态上下线，软负载均衡等。简而言之：有了zookeeper，分布式应用在其上进行注册即可实现集群中的主从管理模式。
其实Zookeeper和eureka是几乎一样的，但是又有一些差别，eureka因为是隶属于微服务里面的，微服务系列是更全面的组件。
Zookeeper的内部原理
选举机制
半数机制：集群中半数以上机器alive则集群可用。所以 zookeeper更适合装在奇数台机器上（容忍度： 奇数台和偶数台机器的容忍度是一样的。3:1,4:1）。并且不同于其他框架的主从机制，zookeeper并没 有在配置文件中界定leader和follower的具体对象，而是在集群启动的时候通过内部选举的方式临时产 生一个leader。
Server一共有如下三种状态： LOOKING ：当前Server不知道leader是谁，正在搜寻
LEADING ：当前Server即为选举出来的leader
FOLLOWING ：leader已经选举出来，当前Server与之同步
那么Zookeeper的内部选举机制是由什么操控的呢？————paxos算法
这个东西也被称为小岛算法。官方的说法大家可以进行百度一下(太长了，我就不粘贴了)
这里子月画了一副图，以便于大家理解
子月不知道如何把这个图片让它正过来╮(╯▽╰)╭
1服务器 1 启动，此时只有它一台服务器启动了，它发出去的报没有任何响应，所以它的选举状态 只能是搜寻其他响应即Looking状态。
2. 服务器 2 启动，它与最开始启动的服务器 1 进行通信，互相交换自己的选举结果，由于两者都没 有历史数据即所谓zxid，所以 myid 值较大的服务器 2 胜出，但是由于没有达到超过半数以上（3 个）的服务器都同意选举它，所以服务器 1、2 还是继续保持LOOKING 状态。
3. 服务器 3 启动，根据前面的理论分析，服务器 3 成为服务器 1、2、3 中的老大，而与上面不同的 是，此时有三台服务器选举了它，所以它成为了这次选举的临时leader。
4. 服务器 4 启动，根据前面的分析，理论上服务器 4 应该是服务器 1、2、3、4 中最大的，但是由于 前面已经有半数以上的服务器选举了服务器 3，所以他也只能当follower了。
5. 服务器 5 启动，同 4 一样当follower了。
Paxos，它是一个基于消息传递的一致性算法，Leslie Lamport在1990年提出，近几年被广泛应用于分 布式计算中，Google的 Chubby，Apache的Zookeeper都是基于它的理论来实现的，Paxos还被认为是 到目前为止唯一的分布式一致性算法，其它的算法都是 Paxos的改进或简化。有个问题要提一下， Paxos有一个前提：没有拜占庭将军问题。就是说Paxos只有在一个可信的计算环境中才能成立，这个 环境是不会被入侵所破坏的
总结两句话：打铁还需自身硬，把握时机很重要。
广播机制
1.首先每个zkServer在内存中存储了一份数据（小）； 2.Zookeeper启动时，将从实例中选举一个leader（Paxos协议） 3.Leader负责处理数据更新等操作 4.一个更新操作成功时机当且仅当大多数Server在内存中成功修改数据。 Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab 协议。 Zab协议有两种模式，它们分别是恢复模式和广播模式。 当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完 成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进 行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到 leader崩溃了或者leader失去了大部分的followers支持。 广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议 (proposal)都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识 leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。 当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一 个新的leader，让所有的server都恢复到一个正确的状态。
Znode数据模型
zookeeper的目录结构与 Unix 文件系统很类似，整体上可以看作是一棵树，这一个树形结构由 zookeeper 集群自身维护，其上的每一个节点，我们称之为"znode"，各自的路径作为节点的唯一标 识。
znode的类型有两种 短暂型 客户端和服务器端断开连接后，创建的节点znode自动删除。
持久型 客户端和服务器端断开连接后，创建的节点znode不会自动删除。
