一、Zookeeper介绍

ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。
分布式应用可以基于它实现更高级的服务，实现诸如同步服务、配置维护和集群管理或者命名的服务。Zookeeper服务自身组成一个集群，2n+1个（奇数）服务允许n个失效，集群内一半以上机器可用，Zookeeper就可用。
假设 3台机器组成的集群，可以有允许一台失效，如果有2台失效，这个集群就不可用，1<1.5，一般的搭建zookeeper集群时，以奇数台机器来搭建。目的：是为了提高容错能允许多损失一台。

1.1 数据模型

1）ZooKeeper本质上是一个分布式的小文件存储系统；
2）Zookeeper表现为一个分层的文件系统目录树结构（不同于文件系统的是，节点可以有自己的数据，而文件系统中的目录节点只有子节点），每个节点可以存少量的数据（1M左右）。
3）每个节点称做一个ZNode。每个ZNode都可以通过其路径唯一标识。

4）ZooKeeper中的每个节点存储的数据要被原子性的操作。也就是说读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。

5）在zookeeper创建顺序节点（create -s ），节点路径后加编号，这个计数对于此节点的父节点来说是唯一的。
/app/
/s100000000001
/s100000000002

6）ZooKeeper中的节点有两种，分别为临时节点和永久节点。节点的类型在创建时即被确定，并且不能改变。
① 临时节点：在客户端用create -e创建，该节点的生命周期依赖于创建它们的会话。一旦会话(Session)结束，临时节点将被自动删除，当然可以也可以手动删除。虽然每个临时的Znode都会绑定到一个客户端会话，但他们对所有的客户端还是可见的。另外，**ZooKeeper的临时节点不允许拥有子节点。
② 永久节点：在客户端用create 创建，该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。

7）客户端可以给节点设置watch，我们称之为监视器。当节点状态发生改变时(Znode的增、删、改)将会触发watch所对应的操作。当watch被触发时，ZooKeeper将会向客户端发送且仅发送一条通知。

分布式锁
zookeeper 是高可用协调流程图

1.2 zookeepr角色介绍

领导者（leader），负责进行投票的发起和决议，更新系统状态（数据同步），发送心跳。
学习者（learner），包括跟随者（follower）和观察者（observer）。
跟随者（follower），用于接受客户端请求、向客户端返回结果，在选主过程中参与投票。
观察者（Observer），可以接受客户端请求，会把请求转发给leader，但observer不参加投票过程，只同步leader的状态，observer的目的是为了扩展系统，提高读取速度。

1）leader失效后会在follower中重新选举新的leader
2）每个follower都和leader有连接，接受leader的数据更新操作
3）客户端可以连接到每个server，每个server的数据完全相同
4）每个节点的服务Server，记录事务日志和快照到持久存储

1.3 工作原理

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式（选主）和广播模式（同步）。

恢复模式：当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，恢复模式不接受客户端请求，当领导者被选举出来，且大多数Server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

广播模式：一旦Leader已经和多数的Follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个Server加入ZooKeeper服务中，它会在恢复模式下启动，发现Leader，并和Leader进行状态同步。待到同步结束，它也参与消息广播。ZooKeeper的广播状态一直到Leader崩溃了或者Leader失去了大部分的Followers支持。

1.4 Zookeeper节点数据操作流程

(1）写操作
1）在Client向Follwer 或 Observer 发出一个写的请求；
2）Follwer 或 Observer 把请求发送给Leader；
3）Leader接收到以后向所有follower发起提案；
4）Follwer收到提案后执行写操作，然后把操作结果发送给Leader；
5）当多数follower返回提案结果后，leader会commit该提议，通知其他Follower 和 Observer 同步信息；
6）Follwer 或Observer把请求结果返回给Client。

(2）读操作
1）在Client向Follwer 或 Observer 发出一个读的请求；
2）Follwer 或 Observer 把请求结果返回给Client；

1.5 主要特点
最终一致性：client不论连接到哪个Server，展示给它都是同一个视图，这是zookeeper最重要的特性；
可靠性：具有简单、健壮、良好的性能，如果消息被某一台服务器接受，那么它将被所有的服务器接受；
实时性：Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息，或者服务器失效的信息。但由于网络延时等原因，Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口；
等待无关(wait-free)：慢的或者失效的client，不得干预快速的client的请求，使得每个client都能有效的等待；
原子性：更新只能成功或者失败，没有中间状态；
顺序性：按照客户端发送请求的顺序更新数据。

1.6 zookeepr应用场景

1.6.1 数据发布与订阅

发布与订阅即所谓的配置管理，顾名思义就是将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。

应用配置集中到节点上，应用启动时主动获取，并在节点上注册一个watcher，每次配置更新都会通知到应用。

1.6.2 命名空间服务 分布式命名服务，创建一个节点后，节点的路径就是全局唯一的，可以作为全局名称使用。

1.6.3 分布式通知/协调
不同的系统都监听同一个节点，一旦有了更新，另一个系统能够收到通知。

1.6.4 分布式锁
Zookeeper能保证数据的强一致性，用户任何时候都可以相信集群中每个节点的数据都是相同的。锁的两种体现方式：
(1）保持独占
一个用户创建一个节点作为锁，另一个用户检测该节点，如果存在，代表别的用户已经锁住，如果不存在，则可以创建一个节点，代表拥有一个锁。

(2）控制时序
有一个节点作为父节点，其底下是带有编号的子节点，所有要获取锁的用户，需要在父节点下创建带有编号的子节点，编号最小的会持有锁；当最小编号的节点被删除后，锁被释放，再重新找最小编号的节点来持有锁，这样保证了全局有序。

1.6.5 集群管理
每个加入集群的机器都创建一个节点，写入自己的状态。监控父节点的用户会收到通知，进行相应的处理。离开时删除节点，监控父节点的用户同样会收到通知。