Zookeeper是Hadoop分布式调度服务，用来构建分布式应用系统。构建一个分布式应用是一个很复杂的事情，主要的原因是我们需要合理有效的处理分布式集群中的部分失败的问题。例如，集群中的节点在相互通信时，A节点向B节点发送消息。A节点如果想知道消息是否发送成功，只能由B节点告诉A节点。那么如果B节点关机或者由于其他的原因脱离集群网络，问题就出现了。A节点不断的向B发送消息，并且无法获得B的响应。B也没有办法通知A节点已经离线或者关机。集群中其他的节点完全不知道B发生了什么情况，还在不断的向B发送消息。这时，你的整个集群就发生了部分失败的故障。
Zookeeper不能让部分失败的问题彻底消失，但是它提供了一些工具能够让你的分布式应用安全合理的处理部分失败的问题。
Zookeeper基本是什么
是一个基于观察者模式设计的分布式服务管理框架，他负责存储和管理大家都关心的数据，然后接受管擦者的注册，一旦这些数据的状态发生了变化，Zookeeper就将负责通知已经在Zookeeper上注册的观察者做出相应的反应。
特点是什么
集群中半数以上的机器存活，Zookeeper集群就可以正常服务。
集群数据保持一致，每一个Server保存一分相同的数据副本，Client无论连接那个Server，数据都是一致的。
Zookeeper的工作机制
Zookeeper: 一个领导者(Leader) , 多个追随者(Follower) 组成的集群;
集群中只要有半数以上节点存活，Zookeeper 集群就能正常服务;
全局数据一致，每个Server保存一份相同的数据副本，Client 无论连接到哪个 Server , 数据都是一致的。
更新请求顺序进行，来自同一个Client 的更新请求按其发送顺序依次执行；
数据更新原子性，一次数据更新要么成功，要么失败。
实时性，在一定时间范围内，Client能读到最新的数据。
Zookeeper 的重要概念Zookeeper 本身就是一个分布式程序（半数以上的节点存活，Zookeeper 就能正常服务）
为了保证高可用，最好是以集群形态来部署 Zookeeper , 这样只要集群中大部分机器是可用的（能够容忍一定的机器故障），那么Zookeeper 本身任然是可用的。
Zookeeper 将数据保存在内存中，这也就保证了高吞吐量和低延迟（但是内存限制了能够存储的容量不太大，此限制也是保持 znode 中存储的数据量较小的进一步原因）。
Zookeeper 是高性能的。在 “读” 多于 “写” 的应用程序中尤其的 高性能。因为“写” 会导致所有的服务器间同步状态（“读” 多于 “写” 是协调服务的典型场景）。
Zookeeper 有临时节点的概念。当创建临时节点的客户端会话一直保持活动，瞬时节点就一直存在。而当会话终结时，瞬时节点被删除。持久节点是指一旦这个 ZNode 被创建，除非主动进行 ZNode 的移除操作，否则这个 ZNode 将一直保存在 Zookeeper 上。
Zookeeper 底层其实只提供了两个功能：① 管理（存储、读取）用户程序提交的数据； ② 为用户程序提交数据节点监听服务
Session (会话)Session 是指 Zookeeper 服务器与客户端会话。在 Zookeeper 中，一个客户端连接是指客户端和服务器之间的 TCP 长连接。客户端启动的时候，首先会和服务器建立一个 TCP 连接，客户端能够通过 心跳 检测和服务保持有效的会话，也能够向 Zookeeper 服务器发送请求并接受响应，同时还能通过该链接接收来自服务器的 Watch 事件通知。
Session 的 sessionTimeout 值用来设置一个客户端会话的超时时间。当用于服务器压力太大、网络故障或是在客户端主动断开连接等各种原因导致客户端连接断开的时，只要在 sessionTimeout 规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话依然有效。
在为客户端创建会话之前，服务端首先会为每个客户端都分配一个 sessionID , 由于 sessionID 是 Zookeeper 会话的一个重要标识，许多与会话相关的运行机制都是基于这个 sessionID 的（也就是，这个 sessionID 全局唯一） 。
Znode在分布式中，所谓的节点是指集群中的每一台机器，称为机器节点。但是在 Zookeeper 中， 我们的节点有两种，一种是 机器节点 ， 另一种就是 数据模型中的数据单元，也就是我们称为的数据节点——Znode 。