一、什么是zookeeper
zooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。Zookeeper致力于为那些高吞吐的大型分布式系统提供一个高性能、高可用、且具有严格顺序访问控制能力的分布式协调服务。
简单来说zookeeper=文件系统+监听通知机制。
二、特性
1.顺序一致性：从一个客户端发起的事务请求，最终都会严格按照其发起顺序被应用到Zookeeper中；对于来自客户端的每个更新请求，Zookeeper都会分配一个全局唯一的递增ID(zxid)，这个ID反映了所有事务请求的先后顺序。
2.原子性：所有事务请求的处理结果在整个集群中所有机器上都是一致的
3.最终一致性：所有客户端看到的服务端数据模型都是一致的；
4.可靠性：一旦服务端成功应用了一个事务，则其引起的改变会一直保留，直到被另外一个事务所更改,如果消息被到一台服务器接受，那么它将被所有的服务器接受。
5.实时性：一旦一个事务被成功应用后，Zookeeper可以保证客户端立即可以读取到这个事务变更后的最新状态的数据。
6.等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。
"由于Zookeeper的所有更新和删除都是基于事务的，所以其在读多写少的应用场景中有着很高的性能表现。" "ZooKeeper将数据存全量储在内存中以保持高性能，并通过服务集群来实现高可用"
三、常见的应用场景
1. 数据的发布/订阅 数据的发布/订阅系统，通常也用作配置中心。在分布式系统中，你可能有成千上万个服务节点，如果想要对所有服务的某项配置进行更改，由于数据节点过多，你不可逐台进行修改，而应该在设计时采用统一的配置中心。之后发布者只需要将新的配置发送到配置中心，所有服务节点即可自动下载并进行更新，从而实现配置的集中管理和动态更新。 Zookeeper通过Watcher机制可以实现数据的发布和订阅。分布式系统的所有的服务节点可以对某个ZNode注册监听，之后只需要将新的配置写入该ZNode，所有服务节点都会收到该事件。
2. 命名服务 在分布式系统中，通常需要一个全局唯一的名字，如生成全局唯一的订单号等，Zookeeper可以通过顺序节点的特性来生成全局唯一ID，从而可以对分布式系统提供命名服务。
3. Master选举 分布式系统一个重要的模式就是主从模式(Master/Salves)，Zookeeper可以用于该模式下的Matser选举。可以让所有服务节点去竞争性地创建同一个ZNode，由于Zookeeper不能有路径相同的ZNode，必然只有一个服务节点能够创建成功，这样该服务节点就可以成为Master节点。
4. 分布式锁 可以通过Zookeeper的临时节点和Watcher机制来实现分布式锁，这里以排它锁为例进行说明： 分布式系统的所有服务节点可以竞争性地去创建同一个临时ZNode，由于Zookeeper不能有路径相同的ZNode，必然只有一个服务节点能够创建成功，此时可以认为该节点获得了锁。其他没有获得锁的服务节点通过在该ZNode上注册监听，从而当锁释放时再去竞争获得锁。锁的释放情况有以下两种： 当正常执行完业务逻辑后，客户端主动将临时ZNode删除，此时锁被释放； 当获得锁的客户端发生宕机时，临时ZNode会被自动删除，此时认为锁已经释放。 当锁被释放后，其他服务节点则再次去竞争性地进行创建，但每次都只有一个服务节点能够获取到锁，这就是排他锁。
5. 集群管理 Zookeeper还能解决大多数分布式系统中的问题： 如可以通过创建临时节点来建立心跳检测机制。如果分布式系统的某个服务节点宕机了，则其持有的会话会超时，此时该临时节点会被删除，相应的监听事件就会被触发。 分布式系统的每个服务节点还可以将自己的节点状态写入临时节点，从而完成状态报告或节点工作进度汇报。 通过数据的订阅和发布功能，Zookeeper还能对分布式系统进行模块的解耦和任务的调度。 通过监听机制，还能对分布式系统的服务节点进行动态上下线，从而实现服务的动态扩容。
6.事务操作 在ZooKeeper中，能改变ZooKeeper服务器状态的操作称为事务操作。一般包括数据节点创建与删除、数据内容更新和客户端会话创建与失效等操作。 对应每一个事务请求，ZooKeeper都会为其分配一个全局唯一的事务ID，用 ZXID 表示，通常是一个64位的数字。每一个 ZXID对应一次更新操作， 从这些 ZXID 中可以间接地识别出 ZooKeeper 处理这些事务操作请求的全局顺序。
四、优缺点
优点：
01.分布式协调过程简单
02.同步: zk高度同步，这意味着服务器进程之间既存在互斥又存在合作，同步有助于Apache HBase进行配置管理。
3.有序消息: zk跟踪一个数字，表示每个更新的顺序，保证消息有序
04.序列化: 根据具体规则，zk对数据进行编码。 另外，它还可确保我们的应用程序始终如一地运行。 但是，在MapReduce中，我们使用此方法（序列化）来协调队列以执行正在运行的线程
05.速度: 在读请求多的情况下，能以很快的速度运行
06.可扩展性: 此外，可以通过部署更多机器来加强zk的性能
07.有序性有何优势？: 众所周知，zk中的消息是有序的。 所以，为了实现更高级别的抽象，需要有序性。 这就是有序性对我们有利的方式
08.快: 在读多的情况下，zk会非常快
09.可靠性: zk非常可靠，因为一旦zk更新了，更新后的数据会一直保持，直到被覆盖更新
10.原子性: zk只有两种情况，要么全部成功，要么全部失败，没有中间状态的情况
11.实时性: zk保证在一定时间段内，客户端最终一定能从服务器上读到最新的数据状态
局限性：
01.增加新的zk服务器时可能导致数据丢失
在现有服务器中，当新zk服务器数量超过zk服务中已存在的数量时数据会丢失。 同时，向zk服务发出Start命令，新服务器可能形成仲裁
02.不能迁移
在没有用户干预的情况下，zk服务器无法从版本3.4迁移到3.3，然后再迁移到3.4。
03.节点数（其实集群中只要存活数过半即对外可用，但是会有脑裂情况发生）
要求3或5个这样奇数个zk节点（要求奇数是为了保证选举的正常进行因为leader选举要求 可用节点数量 > 总节点数/2，防止脑裂造成集群不可用。同时在容错能力相同的情况下，奇数个节点更节省资源）
04.机架感知复制
目前，它不支持机架放置和感知
05.缩容
不支持减少pod的数量，以防止意外数据丢失
06.磁盘变更
不支持在初始部署后更改volume要求，以防止重新分配意外丢失数据
07.虚拟网络
当服务部署在虚拟网络上时，如果没有完全重新安装，服务可能无法切换到主机网络。 另外，对于尝试从主机切换到虚拟网络，它们是相同的情况
08.Kerberos
在虚拟网络上，它目前不支持启用Kerberos
09.支持有限
对跨群集方案的支持非常有限。 但是，没有CP系统会一直支持跨集群。 虽然我们可以说consul似乎在这方面做得更好
10.复杂
它非常重，所以它需要我们维持一个相当大的堆栈