Zookeeper简单介绍
五、ZooKeeper服务中操作
一、分布式协调技术
在给大家介绍ZooKeeper之前先来给大家介绍一种技术——分布式协调技术。那么什么是分布式协调技术？那么我来告诉大家，其实分布式协调技术主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果。
如图1.1所示
二、ZooKeeper概述
ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，它提供了一项基本服务：分布式锁服务。由于ZooKeeper的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护、组服务、分布式消息队列、分布式通知/协调等。
注意：ZooKeeper性能上的特点决定了它能够用在大型的、分布式的系统当中。从可靠性方面来说，它并不会因为一个节点的错误而崩溃。除此之外，它严格的序列访问控制意味着复杂的控制原语可以应用在客户端上。ZooKeeper在一致性、可用性、容错性的保证，也是ZooKeeper的成功之处，它获得的一切成功都与它采用的协议——Zab协议是密不可分的，这些内容将会在后面介绍。
三、ZooKeeper数据模型
3.1 ZooKeeper数据模型Znode
ZooKeeper拥有一个层次的命名空间，这个和标准的文件系统非常相似。
如图： ZooKeeper数据模型与文件系统目录树
从图中我们可以看出ZooKeeper的数据模型，在结构上和标准文件系统的非常相似，都是采用这种树形层次结构，ZooKeeper树中的每个节点被称为—Znode。和文件系统的目录树一样，ZooKeeper树中的每个节点可以拥有子节点。但也有不同之处：
(1) 引用方式 Zonde通过路径引用，如同Unix中的文件路径。路径必须是绝对的，因此他们必须由斜杠字符来开头。除此以外，他们必须是唯一的，也就是说每一个路径只有一个表示，因此这些路径不能改变。在ZooKeeper中，路径由Unicode字符串组成，并且有一些限制。字符串"/zookeeper"用以保存管理信息，比如关键配额信息。 (2) Znode结构 ZooKeeper命名空间中的Znode，兼具文件和目录两种特点。既像文件一样维护着数据、元信息、ACL、时间戳等数据结构，又像目录一样可以作为路径标识的一部分。图中的每个节点称为一个Znode。 每个Znode由3部分组成: ① stat：此为状态信息, 描述该Znode的版本, 权限等信息 ② data：与该Znode关联的数据 ③ children：该Znode下的子节点 ZooKeeper虽然可以关联一些数据，但并没有被设计为常规的数据库或者大数据存储，相反的是，它用来管理调度数据，比如分布式应用中的配置文件信息、状态信息、汇集位置等等。这些数据的共同特性就是它们都是很小的数据，通常以KB为大小单位。ZooKeeper的服务器和客户端都被设计为严格检查并限制每个Znode的数据大小至多1M，但常规使用中应该远小于此值。 (3) 数据访问 ZooKeeper中的每个节点存储的数据要被原子性的操作。也就是说读操作将获取与节点相关的所有数据，写操作也将替换掉节点的所有数据。另外，每一个节点都拥有自己的ACL(访问控制列表)，这个列表规定了用户的权限，即限定了特定用户对目标节点可以执行的操作。 (4) 节点类型 ZooKeeper中的节点有两种，分别为临时节点和永久节点。节点的类型在创建时即被确定，并且不能改变。 ① 临时节点：该节点的生命周期依赖于创建它们的会话。一旦会话(Session)结束，临时节点将被自动删除，当然可以也可以手动删除。虽然每个临时的Znode都会绑定到一个客户端会话，但他们对所有的客户端还是可见的。另外，ZooKeeper的临时节点不允许拥有子节点。 ② 永久节点：该节点的生命周期不依赖于会话，并且只有在客户端显示执行删除操作的时候，他们才能被删除。 (5) 顺序节点 当创建Znode的时候，用户可以请求在ZooKeeper的路径结尾添加一个递增的计数。这个计数对于此节点的父节点来说是唯一的，它的格式为"%10d"(10位数字，没有数值的数位用0补充，例如"0000000001")。当计数值大于232-1时，计数器将溢出。 (6) 观察 客户端可以在节点上设置watch，我们称之为监视器。当节点状态发生改变时(Znode的增、删、改)将会触发watch所对应的操作。当watch被触发时，ZooKeeper将会向客户端发送且仅发送一条通知，因为watch只能被触发一次，这样可以减少网络流量。
3.2 ZooKeeper中的时间
ZooKeeper有多种记录时间的形式，其中包含以下几个主要属性：
(1) Zxid 致使ZooKeeper节点状态改变的每一个操作都将使节点接收到一个Zxid格式的时间戳，并且这个时间戳全局有序。也就是说，也就是说，每个对节点的改变都将产生一个唯一的Zxid。如果Zxid1的值小于Zxid2的值，那么Zxid1所对应的事件发生在Zxid2所对应的事件之前。实际上，ZooKeeper的每个节点维护者三个Zxid值，为别为：cZxid、mZxid、pZxid。 ① cZxid： 是节点的创建时间所对应的Zxid格式时间戳。 ② mZxid：是节点的修改时间所对应的Zxid格式时间戳。 实现中Zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个 新的epoch。低32位是个递增计数。
(2) 版本号 对节点的每一个操作都将致使这个节点的版本号增加。每个节点维护着三个版本号，他们分别为： ① version：节点数据版本号 ② cversion：子节点版本号 ③ aversion：节点所拥有的ACL版本号
3.3 ZooKeeper节点属性
通过前面的介绍，我们可以了解到，一个节点自身拥有表示其状态的许多重要属性，如下图所示。
四、ZooKeeper服务中操作
更新ZooKeeper操作是有限制的。delete或setData必须明确要更新的Znode的版本号，我们可以调用exists找到。如果版本号不匹配，更新将会失败。
更新ZooKeeper操作是非阻塞式的。因此客户端如果失去了一个更新(由于另一个进程在同时更新这个Znode)，他可以在不阻塞其他进程执行的情况下，选择重新尝试或进行其他操作。
尽管ZooKeeper可以被看做是一个文件系统，但是处于便利，摒弃了一些文件系统地操作原语。因为文件非常的小并且使整体读写的，所以不需要打开、关闭或是寻地的操作。
五、Watch触发器
(1) watch概述 ZooKeeper可以为所有的读操作设置watch，这些读操作包括：exists()、getChildren()及getData()。watch事件是一次性的触发器，当watch的对象状态发生改变时，将会触发此对象上watch所对应的事件。watch事件将被异步地发送给客户端，并且ZooKeeper为watch机制提供了有序的一致性保证。理论上，客户端接收watch事件的时间要快于其看到watch对象状态变化的时间。 (2) watch类型 ZooKeeper所管理的watch可以分为两类： ① 数据watch(data watches)：getData和exists负责设置数据watch ② 孩子watch(child watches)：getChildren负责设置孩子watch 我们可以通过操作返回的数据来设置不同的watch： ① getData和exists：返回关于节点的数据信息 ② getChildren：返回孩子列表 因此 ① 一个成功的setData操作将触发Znode的数据watch ② 一个成功的create操作将触发Znode的数据watch以及孩子watch ③ 一个成功的delete操作将触发Znode的数据watch以及孩子watch (3) watch注册与处触发
① exists操作上的watch，在被监视的Znode创建、删除或数据更新时被触发。
② getData操作上的watch，在被监视的Znode删除或数据更新时被触发。在被创建时不能被触发，因为只有Znode一定存在，getData操作才会成功。
③ getChildren操作上的watch，在被监视的Znode的子节点创建或删除，或是这个Znode自身被删除时被触发。可以通过查看watch事件类型来区分是Znode，还是他的子节点被删除：NodeDelete表示Znode被删除，NodeDeletedChanged表示子节点被删除。
(4) 需要注意的几点
Zookeeper的watch实际上要处理两类事件：
① 连接状态事件(type=None, path=null)
这类事件不需要注册，也不需要我们连续触发，我们只要处理就行了。
② 节点事件
节点的建立，删除，数据的修改。它是one time trigger，我们需要不停的注册触发，还可能发生事件丢失的情况。
上面2类事件都在Watch中处理，也就是重载的process(Event event)
节点事件的触发，通过函数exists，getData或getChildren来处理这类函数，有双重作用：
① 注册触发事件
② 函数本身的功能
函数的本身的功能又可以用异步的回调函数来实现,重载processResult()过程中处理函数本身的的功能。
六、使用Zookeeper命令的简单操作步骤
(1) 连接到Zookeeper服务
zkCli.sh -server localhost:2181
(2) 使用ls命令查看当前Zookeeper中所包含的内容：ls /
[zk: localhost:2181(CONNECTED) 1] ls /
[zookeeper]
[zk: localhost:2181(CONNECTED) 2]
(3) 创建一个新的Znode节点"zk"，以及和它相关字符，执行命令：create /zk myData
[zk: localhost:2181(CONNECTED) 2] create /zk myData
Created /zk
(4) 再次使用ls命令来查看现在Zookeeper的中所包含的内容：ls /
[zk: localhost:2181(CONNECTED) 3] ls /
[zk, zookeeper]
此时看到，zk节点已经被创建
(5) 使用get命令来确认第二步中所创建的Znode是否包含我们创建的字符串，执行命令：get /zk
[zk: localhost:2181(CONNECTED) 4] get /zk myData cZxid = 0x500000006 ctime = Fri Oct 17 03:54:20 PDT 2014 mZxid = 0x500000006 mtime = Fri Oct 17 03:54:20 PDT 2014 pZxid = 0x500000006 cversion = 0 dataVersion = 0 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 6 numChildren = 0
(6) 接下来通过set命令来对zk所关联的字符串进行设置，执行命令：set /zk jiang1234
[zk: localhost:2181(CONNECTED) 5] set /zk jiang2014 cZxid = 0x500000006 ctime = Fri Oct 17 03:54:20 PDT 2014 mZxid = 0x500000007 mtime = Fri Oct 17 03:55:50 PDT 2014 pZxid = 0x500000006 cversion = 0 dataVersion = 1 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 9 numChildren = 0
(7) 再次使用get命令来查看，上次修改的内容，执行命令：get /zk
[zk: localhost:2181(CONNECTED) 6] get /zk jiang2014 cZxid = 0x500000006 ctime = Fri Oct 17 03:54:20 PDT 2014 mZxid = 0x500000007 mtime = Fri Oct 17 03:55:50 PDT 2014 pZxid = 0x500000006 cversion = 0 dataVersion = 1 aclVersion = 0 ephemeralOwner = 0x0 dataLength = 9 numChildren = 0
(8) 下面我们将刚才创建的Znode删除，执行命令：delete /zk，rmr /zk
[zk: localhost:2181(CONNECTED) 7] delete /zk
# 整个节点全删除
注意：delete只能删除不包含子节点的节点，如果要删除的节点包含子节点，使用rmr命令
[zk: localhost:2181(CONNECTED) 7] rmr /zk
(9) 最后再次使用ls命令查看Zookeeper中的内容，执行命令：ls /
[zk: localhost:2181(CONNECTED) 8] ls /
[zookeeper]
经过验证，zk节点已经删除。
七、ZooKeeper应用举例
7.1 分布式锁应用场景
在分布式锁服务中，有一种最典型应用场景，就是通过对集群进行Master选举，来解决分布式系统中的单点故障。什么是分布式系统中的单点故障：通常分布式系统采用主从模式，就是一个主控机连接多个处理节点。主节点负责分发任务，从节点负责处理任务，当我们的主节点发生故障时，那么整个系统就都瘫痪了，那么我们把这种故障叫作单点故障。如下图：
主从模式分布式系统 单点故障
7.2 传统解决方案
传统方式是采用一个备用节点，这个备用节点定期给当前主节点发送ping包，主节点收到ping包以后向备用节点发送回复Ack，当备用节点收到回复的时候就会认为当前主节点还活着，让他继续提供服务。所示：
传统解决方案
当主节点挂了，这时候备用节点收不到回复了，然后他就认为主节点挂了接替他成为主节点如下图所示：
传统解决方案
但是这种方式就是有一个隐患，就是网络问题，来看一网络问题会造成什么后果，如下图所示：
网络故障
也就是说我们的主节点的并没有挂，只是在回复的时候网络发生故障，这样我们的备用节点同样收不到回复，就会认为主节点挂了，然后备用节点将他的Master实例启动起来，这样我们的分布式系统当中就有了两个主节点也就是---双Master，出现Master以后我们的从节点就会将它所做的事一部分汇报给了主节点，一部分汇报给了从节点，这样服务就全乱了。为了防止出现这种情况，我们引入了ZooKeeper，它虽然不能避免网络故障，但它能够保证每时每刻只有一个Master。我么来看一下ZooKeeper是如何实现的。
7.3 ZooKeeper解决方案
(1) Master启动
在引入了Zookeeper以后我们启动了两个主节点，"主节点-A"和"主节点-B"他们启动以后，都向ZooKeeper去注册一个节点。我们假设"主节点-A"锁注册地节点是"master-00001"，"主节点-B"注册的节点是"master-00002"，注册完以后进行选举，编号最小的节点将在选举中获胜获得锁成为主节点，也就是我们的"主节点-A"将会获得锁成为主节点，然后"主节点-B"将被阻塞成为一个备用节点。那么，通过这种方式就完成了对两个Master进程的调度。
ZooKeeper Master选举
(2) Master故障
如果"主节点-A"挂了，这时候他所注册的节点将被自动删除，ZooKeeper会自动感知节点的变化，然后再次发出选举，这时候"主节点-B"将在选举中获胜，替代"主节点-A"成为主节点。
ZooKeeper Master选举
(3) Master 恢复
ZooKeeper Master选举
如果主节点恢复了，他会再次向ZooKeeper注册一个节点，这时候他注册的节点将会是"master-00003"，ZooKeeper会感知节点的变化再次发动选举，这时候"主节点-B"在选举中会再次获胜继续担任"主节点"，"主节点-A"会担任备用节点。
八、ZooKeeper原理
8.1 原理概述
Zookeeper的核心是原子广播机制，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。
(1) 恢复模式
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。
(2) 广播模式
一旦Leader已经和多数的Follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个Server加入ZooKeeper服务中，它会在恢复模式下启动，发现Leader，并和Leader进行状态同步。待到同步结束，它也参与消息广播。ZooKeeper服务一直维持在Broadcast状态，直到Leader崩溃了或者Leader失去了大部分的Followers支持。
Broadcast模式极其类似于分布式事务中的2pc（two-phrase commit 两阶段提交）：即Leader提起一个决议，由Followers进行投票，Leader对投票结果进行计算决定是否通过该决议，如果通过执行该决议（事务），否则什么也不做。
两阶段提交
在广播模式ZooKeeper Server会接受Client请求，所有的写请求都被转发给领导者，再由领导者将更新广播给跟随者，而查询和维护管理命令不用跟leader打交道。当半数以上的跟随者已经将修改持久化之后，领导者才会提交这个更新，然后客户端才会收到一个更新成功的响应。这个用来达成共识的协议被设计成具有原子性，因此每个修改要么成功要么失败。
ZooKeeper数据流动图
九、ZooKeeper中Observer【ZooKeeper伸缩性】
9.1：引入Observer原因
在Observer出现以前，ZooKeeper的伸缩性由Follower来实现，我们可以通过添加Follower节点的数量来保证ZooKeeper服务的读性能。但是随着Follower节点数量的增加，ZooKeeper服务的写性能受到了影响；Zab协议对写请求的处理过程中我们可以发现，增加服务器的数量，则增加了对协议中投票过程的压力，随着 ZooKeeper 集群变大，写操作的吞吐量会下降；所以，我们不得不，在增加Client数量的期望和我们希望保持较好吞吐性能的期望间进行权衡，要打破这一耦合关系，我们引入了不参与投票的服务器，称为 Observer。Observer可以接受客户端的连接，并将写请求转发给Leader节点。但是，Leader节点不会要求 Observer参加投票。相反，Observer不参与投票过程，仅仅在上述第3歩那样，和其他服务节点一起得到投票结果。
Observer 写吞吐量测试
从上图显示了一个简单评测的结果。纵轴是，单一客户端能够发出的每秒钟同步写操作的数量。横轴是 ZooKeeper 集群的尺寸。蓝色的是每个服务器都是投票Server的情况，而绿色的则只有三个是投票Server，其它都是 Observer。从图中我们可以看出，我们在扩充 Observer时写性能几乎可以保持不便。但是，如果扩展投票Server的数量，写性能会明显下降，显然 Observers 是有效的。
这个简单的扩展，给 ZooKeeper 的可伸缩性带来了全新的镜像。我们现在可以加入很多 Observer 节点，而无须担心严重影响写吞吐量。但他并非是无懈可击的，因为协议中的通知阶段，仍然与服务器的数量呈线性关系。但是，这里的串行开销非常低。因此，我们可以认为在通知服务器阶段的开销无法成为主要瓶颈。
十、利用zookeeper处理脑裂问题
10.1、利用zookeeper的选取leader的过半机制原理实现，所以部署集群最好基数台。
例如：假设5台，至少得有(5/2 + 1)台正常，也就是3台正常，所以最多只能挂掉2台，而6台也是最多只能挂掉2台，这就是为啥最好使用基数台。
10.2、没有leader是无法对外提供服务的，所以要么只有一个leader对外提供服务，要么不对外提供服务，所以不会出现2个leader对外提供服务，因此解决了脑裂的问题。
