Zookeeper简介

一、什么是zookeeper

二、ZAB协议概述

一、什么是zookeeper

1、zookeeper是一个高效的分布式的协调服务，他暴露了一些公共服务，比如命名/配置/管理/同步控制/群组服务等。我们可以使用ZK来实现比如达成共识/集群管理/leader选举等。

zookeeper是一个高可用的分布式管理和协调框架，基于ZAB协议（原子消息广播协议）的实现、该框架能保证分布式环境中的数据一致性。也正是基于这样的特性，是的zookeeper成为了解决分布式一致性问题的利器。比如我有三台服务器，一台是leader，2台follow，加入在集群有一条数据数据是1，我想把这条数据改成2，假如当我操作某一个节点的时候，其他的Client是无法访问该节点的，必须操作完节点之后，然后将消息传递给另外2台服务器，并且返回成功之后，其他的Client才能访问该节点。消息传递使用的算法Paxos算法（类似于复制）。

顺序一致性：从一个客户端发起的事物请求，最终将会严格地按照其发起的顺序被应用到zookeeper中去。

原子性：所有事务的请求结果在整个集群中所有机器上的应用情况是一致的，也就是说，要么在整个集群中所有机器上都成功应用了某一个事务，要么都没有应用，没有中间状态；
单一视图：无论客户端连接的是哪个Zookeeper服务器，其看到的服务端数据模型都是一致的。
实时性：Zookeeper仅仅保证在一定的时间内，客户端最终一定能够从服务端上读到最终的数据状态。

2、Zookeeper的设计目标

简单的数据结构：Zookeeper就是以简单的树形结构来进行协调的（也叫树形名字空间）

可以构建集群：一般Zookeeper通常有一组机器构成，一般3-5台机器就可以组成一个Zookeeper集群，只要集群中超过半数的机器能够正常工作，整个集群就能对外提供服务。

顺序访问：对于来自客户端的每个更新请求，Zookeeper都会分配一个全局唯一递增编号，这个编号反映了所有事物操作的先后顺序，应用程序可以使用Zookeeper的这个特性来实现更加高层的同步原语。

高性能：由于zookeeper将全量数据存储在内存中，并直接服务与所有的非实物请求，因此尤其是在读操作为主的场景性能非常突出。在JMater压力测试下（100%读请求场景下），其结果大约在12-13W的QPS。

3、Zookeeper的数据模型

Zookeeper维护了一个具有层级关系的数据结构，它非常类似于一个标准的文件系统。

 1). 每个子目录项如 NameService 都被称作为 znode，这个 znode 是它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1
 2). znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL(短暂的，相对应的就是PERSISTENT持久的) 类型的目录节点不能有子节点目录
     四种类型的节点：
     PERSISTENT：持久化目录节点，这个目录节点存储的数据不会丢失；
     PERSISTENT_SEQUENTIAL：顺序自动编号的目录节点，这种目录节点会根据当前已近存在的节点数自动加 1，然后返回给客户端已经成功创建的目录节点名；
     EPHEMERAL：临时目录节点，一旦创建这个节点的客户端与服务器端口也就是 session 超时，这种节点会被自动删除；
     EPHEMERAL_SEQUENTIAL：临时自动编号节点
3). znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据
4). znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除

5). znode 的目录名可以自动编号，如APP1已经存在，再创建的话，将会自动命名为APP2
6). znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的。

4、Zookeeper 的组成

ZK server根据其身份特性分为三种：leader，Follower，Observer，其中Follower和Observer又统称Learner（学习者）。
    Leader：负责客户端的writer类型请求
    Follower：负责客户端的reader类型请求，参与leader选举等
    Observer：特殊的“Follower”，其可以接受客户端reader请求，但不参与选举。（扩容系统支撑能力，提高了读取速度。因为它不接受任何同步的写入请求，只负责与leader同步数据），也叫做watcher，也就是我们自己写的应用（客户端），也就是Zookeeper的使用者。

5、Zookeeper 应用场景

Zookeeper 从设计模式角度来看，是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者做出相应的反应，从而实现集群中类似 Master/Slave 管理模式

1、配置管理：配置的管理在分布式应用环境中很常见，比如我们在平常的应用系统中，经常会碰到这样的需求：如机器在配置列表，运行时开关配置、数据库配置信息等，这些全局配置信息通常具备以下三个特性

1)数据量比较小

2)数据内容在运行时动态发生变化。

3)集群中各个节点共享信息，配置一致。

2、集群管理：Zookeeper不仅能够帮你维护当前集群中机器的服务状态，而且能帮你选出‘’总管‘’让这些总管来管理集群，这就是Zookeeper的另外一个功能Leader,并实现集群容错功能。

1)希望知道当前集群中究竟有多少机器工作

2)对集群中每天集群的运行时状态进行数据收集

3)对集群中国每台集群进行上下线操作

3、发布与订阅：Zookeeper是一个典型的发布/订阅模式的分布式数控管理与协调框架，开发人员可以使用他来进行分布式数据的发布与订阅
4、数据库切换:比如我们初始化Zookeeper的时候读取其节点上的数据库配置文件，当配置一单发送变更的时候，Zookeeper就能够帮助我们把变更的通知发送到个个客户端，每个
5、分布式事务收集：我们可以做一个日志系统收集集群中所有的日志信息，进行统一管理。
6、分布式锁和队列管理等等

7、Zookeeper的特性就是在分布式场景下高可用，但是原声的API实现分布式功能非常困难，团队去实现也非常的浪费时间，即使实现了也未必稳定，那么可以采用第三方的客户端的完美实现，比如Curator框架。

Zookeeper的应用场景非常广泛：比如Hadoop、strom、消息中间件、分布式数据库同步系统。

二、ZAB协议概述

在说ZAB协议之前需要说另外一个算法Paxos算法

Paxos算法:在这篇博客中http://www.cnblogs.com/endsock/p/3480093.html 也讲得非常清楚，大致情况如下：

在paxos算法中，分为4种角色：

 Proposer ：提议者(1~N个都可以)

 Acceptor：决策者(需要奇数个)

 Client：产生议题者

 Learner：最终决策学习者

 

上面4种角色中，提议者和决策者是很重要的，其他的2个角色在整个算法中应该算做打酱油的，Proposer就像Client的使者，由Proposer使者拿着Client的议题去向Acceptor提议，让Acceptor来决策。这里上面出现了个新名词：最终决策。现在来系统的介绍一下paxos算法中所有的行为：

 

Proposer提出议题

Acceptor初步接受 或者 Acceptor初步不接受

如果上一步Acceptor初步接受则Proposer再次向Acceptor确认是否最终接受

Acceptor 最终接受 或者Acceptor 最终不接受

上面Learner最终学习的目标是Acceptor们最终接受了什么议题？注意，这里是向所有Acceptor学习，如果有多数派个Acceptor最终接受了某提议，那就得到了最终的结果，算法的目的就达到了。画一幅图来更加直观：

 

为什么需要3个Acceptor？因为Acceptor必须是最少大于等于3个，并且必须是奇数个，因为要形成多数派嘛，如果是偶数个，比如4个，2个接受2个不接受，各执己见，没法搞下去了。

为什么是3个Proposer？ 其实无所谓是多少个了，1~n 都可以的；如果是1个proposer，毫无竞争压力，很顺利的完成2阶段提交，Acceptor们最终批准了事。如果是多个proposer就比较复杂了，请继续看。

 

现在通过一则故事来学习paxos的算法的流程(2阶段提交)，有2个Client(老板，老板之间是竞争关系)和3个Acceptor(政府官员)：

 

现在需要对一项议题来进行paxos过程，议题是“A项目我要中标！”，这里的“我”指每个带着他的秘书Proposer的Client老板。

Proposer当然听老板的话了，赶紧带着议题和现金去找Acceptor政府官员。

作为政府官员，当然想谁给的钱多就把项目给谁。

Proposer-1小姐带着现金同时找到了Acceptor-1~Acceptor-3官员，1与2号官员分别收取了10比特币，找到第3号官员时，没想到遭到了3号官员的鄙视，3号官员告诉她，Proposer-2给了11比特币。不过没关系，Proposer-1已经得到了1,2两个官员的认可，形成了多数派(如果没有形成多数派，Proposer-1会去银行提款在来找官员们给每人20比特币，这个过程一直重复每次+10比特币，直到多数派的形成)，满意的找老板复命去了，但是此时Proposer-2保镖找到了1,2号官员，分别给了他们11比特币，1,2号官员的态度立刻转变，都说Proposer-2的老板懂事，这下子Proposer-2放心了，搞定了3个官员，找老板复命去了，当然这个过程是第一阶段提交，只是官员们初步接受贿赂而已。故事中的比特币是编号，议题是value。

　　　　这个过程保证了在某一时刻，某一个proposer的议题会形成一个多数派进行初步支持；

 

 ===============华丽的分割线，第一阶段结束================

 

　　5.　现在进入第二阶段提交，现在proposer-1小姐使用分身术(多线程并发)分了3个自己分别去找3位官员，最先找到了1号官员签合同，遭到了1号官员的鄙视，1号官员告诉他proposer-2先生给了他11比特币，因为上一条规则的性质proposer-1小姐知道proposer-2第一阶段在她之后又形成了多数派(至少有2位官员的赃款被更新了);此时她赶紧去提款准备重新贿赂这3个官员(重新进入第一阶段)，每人20比特币。刚给1号官员20比特币， 1号官员很高兴初步接受了议题，还没来得及见到2,3号官员的时候

 

这时proposer-2先生也使用分身术分别找3位官员(注意这里是proposer-2的第二阶段)，被第1号官员拒绝了告诉他收到了20比特币，第2,3号官员顺利签了合同，这时2，3号官员记录client-2老板用了11比特币中标，因为形成了多数派，所以最终接受了Client2老板中标这个议题，对于proposer-2先生已经出色的完成了工作；

 

这时proposer-1小姐找到了2号官员，官员告诉她合同已经签了，将合同给她看，proposer-1小姐是一个没有什么职业操守的聪明人，觉得跟Client1老板混没什么前途，所以将自己的议题修改为“Client2老板中标”，并且给了2号官员20比特币，这样形成了一个多数派。顺利的再次进入第二阶段。由于此时没有人竞争了，顺利的找3位官员签合同，3位官员看到议题与上次一次的合同是一致的，所以最终接受了，形成了多数派，proposer-1小姐跳槽到Client2老板的公司去了。

 

===============华丽的分割线，第二阶段结束===============

 

Paxos过程结束了，这样，一致性得到了保证，算法运行到最后所有的proposer都投“client2中标”所有的acceptor都接受这个议题，也就是说在最初的第二阶段，议题是先入为主的，谁先占了先机，后面的proposer在第一阶段就会学习到这个议题而修改自己本身的议题，因为这样没职业操守，才能让一致性得到保证，这就是paxos算法的一个过程。原来paxos算法里的角色都是这样的不靠谱，不过没关系，结果靠谱就可以了。该算法就是为了追求结果的一致性。

===============华丽的分割线，Paxos过程结束了===============

ZAB协议概述

ZooKeeper并没有完全采用Paxos算法，而是使用了一种称为ZooKeeperAtomic Broadcast(ZAB,zookeeper原子消息广播协议)的协议作为其数据一致性的核心算法。

ZAB协议是为分布式协调服务ZooKeeper专门设计的一种支持漰溃恢复的原子广播协议。

ZooKeeper实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性。具体，ZooKeeper使用一个单一的主进程来接收并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器的状态变更以事务Proposal的形式广播到所有的副本进程上去。ZAB协议的这个主备模型架构保证了同一时刻集群中只能够有一个主进程来广播服务器的状态变更，因此能够很好地处理客户端大量并发请求。

所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器称为Leader服务器，而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal(提议)，并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确反馈后，那么Leader就会再次向所有的Follower服务器分发Commit消息，要求其将前一个Proposal进行提交。

有上面的算法我们得出结论：zookeeper没有单节点部署，最少是3个节点，也就是奇数个节点，能不能部署4个、6个等个节点，其实也可以，只是不利于paxos算法选举。