简介：
ZooKeeper：为分布式应用提供了高效且可靠的分布式协调服务，提供了诸如统一命名服务、配置管理和分布式锁等分布式的基础服务。
Zookeeper介绍：
是一个开放源代码的分布式协调服务，设计目标是将那些复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。
ZooKeeper是什么：
是一个典型的分布式数据一致性的解决方案，分布式应用程序可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。ZooKeeper可以保证如下分布式一致性特性：
- 顺序一致性
- 原子性
- 单一视图（Single System Image）
- 可靠性
- 实时性
ZooKeeper的设计目标：
致力于提供一个高性能、高可用，且具有严格的顺序访问控制能力（主要是写操作的严格顺序性）的分布式协调服务。高性能使得ZooKeeper能够应用于那些对系统吞吐有明确要求的大型分布式系统中，高可用使得分布式的单点问题得到了很好的解决，而严格的顺序访问控制使得客户端能够基于ZooKeeper实现一些复杂的同步原语。
四个设计目标：
1、 简单的数据模型：通过一个共享的、树型结构的名字空间来进行相互协调。名字空间由一系列ZNode的数据节点组成，数据模型类似于一个文件系统，而ZNode之间的层级关系，就像文件系统的目录结构一样。
2、 可以构建集群：ZooKeeper的客户端程序会选择和集群中任意一台机器共同来创建一个TCP连接，而一旦客户端和某台ZooKeeper服务器之间的连接断开后，客户端会自动连接到集群中的其它机器。
3、 顺序访问：对于来自客户端的每个更新请求，ZooKeeper都会分配一个全局唯一的递增编号，这个编号反应了所有事务操作的先后顺序。
4、 高性能：ZooKeeper将全亮数据存储在内存中，一次来实现提高服务器吞吐、减少延迟的目的。
ZooKeeper的基本概念
集群角色：
最典型的集群模式就是Maste/Slave（主备模式）。在这种模式中，能够处理所有写操作的机器就是Master机器，把所有通过异步复制方式获取最新数据，并提供读服务的机器成为Slave机器。
但是ZooKeeper没有沿用传统的Master/Slave概念，而是引用了Leader、Follower和Observer三种角色。
- Leeder服务器提供读和写服务。
- Follower和Observer都能提供读服务，唯一的区别在于，Observer机器不参与Leader选举过程，也不参与写操作的“过半写成功”策略，因此Observer可以不影响写性能的情况下提升集群的度性能。
会话（Session）：
指的是客户端会话，在ZooKeeper中，一个客户端连接是指客户端和服务器之间的一个TCP长连接。对外的默认端口是2181，客户端启动的时候，首先会与服务器建立一个TCP连接，通过这个连接，客户端能够通过心跳检测与服务器保持有效的会话，也能够向ZooKeeper服务器发送请求并接收响应，同时还能通过该连接接收来自服务器的Watch事件通知。
数据节点（ZNode）
有两种类型，第一种是指构成集群的机器，称之为机器节点；第二种是指数据模型中的数据单元。
ZNode分为持久节点和临时节点两类。持久节点是指一旦这个ZNode被创建了，除非主动进行ZNode的移除操作，否则这个Znode将一直保存在ZooKeeper上。而临时节点它的生命周期和客户端的会话绑定，一旦客户端会话失效，那么这个客户端创建的所有临时节点都会移除。
另外，ZooKeeper还允许用户为每个节点添加一个特殊的属性：SEQUENTIAL。一旦节点呗标记上这个属性，那么在这个节点被创建的时候，ZooKeeper会自动在其节点后面追加一个整型数字，这个整型数据就是一个由父节点维护的自增数字。
版本（Version）
ZooKeeper的每个ZNode上都会存储数据，对应于每个ZNode，ZooKeeper都会为其维护一个叫做Stat的数据结构，Stat中记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本），cversion（当前ZNode的子节点的版本）和aversion（当前ZNode的ACL版本）。
Watcher（事件监听器）
zooKeeper允许用户在制定节点上注册一些Watcher，并且在一些特定时间触发的时候，ZooKeeper服务端会将事件通知到感兴趣的客户端上去。
ACL（Access Control Lists）有以下五种权限
- CREATE：创建子节点的权限
- READ：获取节点数据和子节点列表的权限
- WRITE：更新节点数据的权限
- DELETE：删除子节点的权限
- ADMIN：设置节点的ACL的权限
ZAB协议
ZooKeeper采用了ZooKeeper Atomic Broadcast（ZAB，ZooKeeper源自消息广播协议）作为其数据一致性的核心算法
支持崩溃回复的原子广播协议。依赖ZAB协议来支持集群中个副本之间数据的一致性。
具体的，ZooKeeper使用一个丹仪的主进程来接收并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器数据的状态变更以事务Proposal的形式广播到所有的副本进程上去。
ZAB协议的这个主备模式架构保证了同一时刻集群中只能够有一个主进程来广播服务器的状态变更，因此能够很好地处理客户端大量的并发请求。
ZAB两种基本的模式
1、崩溃恢复
当整个服务框架在启动过程中，或是当Leader服务器出现网络终端、崩溃退出与重启等异常情况时，ZAB协议就会进入恢复模式并选举产生新的Leader服务器。当选举产生了新的Leader服务器，同时集群中已经有过半的机器与该Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式。（状态同步指的是数据同步）
当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就可以进入消息广播模式。
2、消息广播
消息广播过程使用的是一个源自广播协议，类似于一个二阶段提交过程。
针对客户端的事务请求，Leader服务器会为其生成对应的事务Proposal，并将其发送给集群中其余所有的机器，然后再分别收集各自的选票，最后进行事务提交
整个消息广播协议是基于具有FIFO特性的TCP协议来进行网络通信的，因此能够很容易地保证消息广播过程中消息接收和发送的顺序性。
总结：ZAB协议规定了如果一个事务Proposal在一台机器上被处理成功，那么应该在所有的机器上都被处理成功，哪怕机器出现故障崩溃。ZAB协议需要确保那些已经在Leader服务器上提交的事务最终被所有服务器都提交。
深入ZAB协议
系统模型
如果一个进程正常工作，那么我们称该进程处于UP状态；如果一个进程崩溃了，那么我们称其处于DOWN状态。
事实上，当集群中存在过半的处于UP状态的进程组成一个进程子集之后，就可以进行正常的消息广播了。这样的子集称为Quorum。
P1和P2分别代表进程组中的两个不同进程，使用C12来表示进程P1和P2之间的网络通信通道，其满足如下两个基本特性：
1、完整性（Integrity）
2、前置性（Prefix）
问题描述
规定了任何时候都需要保证只有一个主进程负责进行消息广播，而如果主进程崩溃了，就需要选举一个新的主进程。主进程的选举机制和消息广播机制是紧密相关的。
主进程周期
为了保证主进程每次广播出来的事务消息都是一致的，必须确保ZAB协议只有在充分完成崩溃恢复阶段之后，新的主进程才可以开始新的事务消息广播。假设各个进程都实现类似于ready(e)这样的一个函数调用，在运行过程中，ZAB协议能够非常明确地告知上层系统是否可以开始进行事务消息的广播。
事务
假设存在类似于transaction(v,z)这样的函数调用，来实现主进程对状态变更的广播。
主进程每次对transaction(v,z)函数的调用都包含了两个字段：事务内容v和事务标致z，而每一个事务标致z=
针对每一个新的事务，主进程都会首先将事务计数递增。
算法描述
细分为三个阶段：
1、发现（discovery）：
2、同步（Synchronization）
3、广播（Broadcast）
运行分析
每一个进程都有可能处于以下三种状态之一：
1、LOOKING：Leader选举阶段
2、FOLLOWING：Follower服务器和Leader保持同步状态
3、LEADING：Leader服务器作为主进程领导状态