Zookeeper是一个高可用性，高性能的协调服务
Zookeeper解决哪些问题在分布式应用中，经常会出现部分失败的情况，即当节点间传递消息的时候由于网络或者接收者进程死掉等原因，发送者无法知道接收者是否收到消息。
由于部分失败是分布式系统固有的特征因此zookeeper并不能避免部分失败，但是它可以帮你在部分失败的时候进行正确处理
为了解决这个问题Zookeeper具有以下特征：1：zookeeper提供丰富的构件（building block）来实现很多协调数据结构和协议
2：访问原子性，客户端要么读到所有数据，要么读取失败，不会出现只读取部分的情况
3：zookeeper运行在一组机器上，具有高可用性，帮助系统避免单点故障，同时删掉故障服务器
4：顺序一致性：任意客户端的更新请求会被按照发送顺序提交
5：单一系统映像：当一台服务器故障，导致它的客户端需要连接其它服务器的时候，所有更新晚于故障服务器的服务器都不会接收请求，一直到更新赶上故障服务器
6：及时性：任何客户端能看到的滞后都是有限的，不会超过几十秒，且提供sync操作强制客户端所连的服务器与领导者同步
7：会话：每个客户端连接时会尝试连接到配置列表中的一台服务器，一旦失败会自动连接另一台服务器依次类推，知道成功连接一台服务器，从而创建一个会话，客户端可以位每个会话设置超时时间，一旦会话过期，则所有短暂znode会丢失，因为zookeeper会自动发送心跳包，所以很少发生
8：约会机制（rendezvous），在交互的过程中，被协调的各方不许要事先彼此了解，甚至不必同时存在
9：ACL：zookeeper提供了digest（通过用户名密码），host（通过主机名），ip（通过ip地址）3种身份验证模式，依赖与zookeeper的身份验证机制每个ACL都是一个身份对应一组权限，如果我们要给demo.com的客户端域一个读权限在java语言中可以这样创建：
new ACL(Perms.READ, new Id("host", "demo.com"));
Ids.OPEN_ACL_UNSAFE是将所有ADMIN之外的权限授予每个人
另zookeeper还可以集成第三方的身份验证系统
10：提供关于通用协调模式的开源共享资源库
11：高性能的（官方数据）对以写为主的工作负载来说使用5台不错的机器基准吞吐量达到10000+
Zookeeper原理zookeeper使用zab协议，类似Paxos算法但在操作方面却是不同的，该协议包括2个不断重复的阶段
领导者选举：集群所有机器一起选出一台领导者，其它机器成为跟随者，一旦半数以上的跟随者将状态同步，表示这个阶段完成（官方数据这个阶段秩序200毫秒）
原子广播：所有机器将写操作转发给领导者，领导者再将更新广播给跟随者，只有半数以上的跟随者同步修改之后领导者才会提交更新，客户端才能收到更新成功的信息
它的核心是一个精简的文件系统,形成一个树状的数据结构，统一使用节点（znode）的概念，节点可以有子节点，也可以用来保存数据，并且有一个关联的ACL，因为zookeeper被设计来实现协调服务，通常使用小数据文件所以znode能存储的数据限制在1M以内
zookeeper采用斜杠分割的Unicode字符串来做引用类似文件系统路径，但必须是标准的，不支持./这种特殊字符，使用/zookeeper子树来保存管理信息
客户端与服务器通信采用tcp长连接，客户端和服务器通过心跳来保持seesion的连接。当session失效时临时节点会被删除。
通过监控节点以及节点的变化来实现功能，例如集群管理，配置的集中管理，分布式锁等
zookeeper通过复制实现高可用性，只要集群中半数以上的机器可用，就能提供服务，所以一个集群通常要奇数台机器
zookeeper的生命周期有以下3个状态：CONNECTION,CONNECTED,CLOSED
新产生的zookeeper实例是CONNECTION状态，通过建立连接进入CONNECTED状态，当zookeeper实例断开和重连的时候，zookeeper实例在CONNECTED和COONECTION之间转换，调用close方法或者会话超时会进入到CLOSE状态且不能恢复
znode特性
znode有2种，短暂node和持久node，在创建时确定，并且不能修改，短暂node在客户端session结束的时候会被移除
且不可以创建任何类型的子节点
如果在创建znode的时候设置了顺序标识，那么此znode会通过父节点维护的一个单调递增的计数器来添加一个顺序号，这个顺序号可以被用来进行全局排序
watch机制可以让客户端得到znode的变化，观察只能触发一次，为了能多次收到通知，客户端需要重新注册所需的观察
