标签：
ZooKeeper是一个构建在Paxos算法上的高可用的分布式数据管理与系统协调框架，提供了一系列原语集，更上层的应用可以用它来实现同步，配置管理，名称服务，Master选举，分布式锁，分布式队列等。
ZooKeeper提供如下服务保证
ZooKeeper允许分布式进程之间通过一个共享的层级命名空间来相互协作，这个命名空间以类似于文件系统的方式组织起来。命名空间中的数据单元被称为znode，它相当于文件或者目录。与典型文件系统不同的是，文件系统用于持久化存储，而ZooKeeper的数据是保持在内存中的，这意味着ZooKeeper能达到很高的吞吐量和低延迟。
高性能使得ZooKeeper能用于大规模分布式系统，高可用性能避免单点故障，严格的顺序化意味着复杂的同步操作可以在客户端实现。
ZooKeeper本身也是有集群化的。如下图：
客户端与单个服务端相连，它维持一个TCP连接，在其上发送请求，获得响应，获得监控事件和发送心跳检测。如果到服务端的TCP连接断了，客户端会连接另一个服务端。组成ZooKeeper服务的每个服务端都知道其它服务端的存在，它们维护一个服务端状态的内存镜像，连同事务日志和快照保存在持久化存储中，只要大部分服务端可用，ZooKeeper服务就可用。
ZooKeeper为每个更新操作都标记一个号码以反映事务的顺序。后来的操作使用这个顺序来实现高度的抽象，比如同步原语。
这个特性在以读操作为主的工作中尤为明显。ZooKeeper应用程序运行于数以千计的机器中，当读操作与写操作的比例为10:1时，ZooKeeper能获得最佳性能。
所有的server组成一个从ZooKeeper的服务，server和server之间的交互是通过协议进行通信，选取出一个leader，负责向follower广播所有变化消息。其实所有的follower都和leader通信，follower接受来自leader的所有变化信息，保存在自己的内存。follower转发来自客户端的写请求给leader。客户端的读请求会在follower端直接服务，无须转发给leader。
首先2011年Yahoo公开了Zab协议论文。第二选举了leader，只有leader才能提出决议。这就意味着其实跟消息发送的次序是非常有关系的，所以内部的通信基本上都是通过TPS来做的。第三没有abort的两段式提交。第四是基于状态增量的消息传输。第五是高可用、高性能。
ZooKeeper的数据模型极像一个标准的文件系统，一个名字是一个以/分隔的路径元素的序列，ZooKeeper命名空间的每个节点通过路径来标识。
ZooKeeper的视图结构类似标准的Unix文件系统，但是没有引入文件系统相关概念：目录和文件，而是使用了自己特有的节点(node)概念，称为znode。Znode是ZooKeeper中数据的最小单元，每个znode上都可以保存数据，同时还可以挂载子节点，也构成了一个层次化的命名空间，我们称之为树。
ZooKeeper的每个节点是有生命周期的，这取决于节点的类型。在ZooKeeper中，节点类型可以分为持久节点（PERSISTENT ）、临时节点（EPHEMERAL），以及时序节点（SEQUENTIAL ），具体在节点创建过程中，一般是组合使用，可以生成以下4种节点类型：
1、持久节点（PERSISTENT）
所谓持久节点，是指在节点创建后，就一直存在，直到有删除操作来主动清除这个节点——不会因为创建该节点的客户端会话失效而消失。
2、持久顺序节点（PERSISTENT_SEQUENTIAL ）
这类节点的基本特性和上面的节点类型是一致的。额外的特性是，在ZK中，每个父节点会为他的第一级子节点维护一份时序，会记录每个子节点创建的先后顺序。基于这个特性，在创建子节点的时候，可以设置这个属性，那么在创建节点过程中，ZK会自动为给定节点名加上一个数字后缀，作为新的节点名。这个数字后缀的上限是整型的最大值。
3、临时节点（EPHEMERAL ）
和持久节点不同的是，临时节点的生命周期和客户端会话绑定。也就是说，如果客户端会话失效，那么这个节点就会自动被清除掉。注意，这里提到的是会话失效，而非连接断开。另外，在临时节点下面不能创建子节点。
4、临时顺序节点（EPHEMERAL_SEQUENTIAL）
[zk: localhost:2181(CONNECTED) 4] get /YINSHI.MONITOR.ALIVE.CHECK
?t 10.232.102.191:21811353595654255
cZxid = 0x300000002
ctime = Thu Dec 08 23:29:53 CST 2011
mZxid = 0xe00008bbf
mtime = Thu Jul 28 07:17:34 CST 2012
pZxid = 0x300000002
cversion = 0
dataVersion = 2164293
aclVersion = 0
ephemeralOwner = 0x0
dataLength = 39
numChildren = 0
上面这个信息，是在ZK命令行的一个输出信息，从这个输出内容中可以清楚的看到，ZK的一个节点包含了哪些信息。其中比较重要的信息包括节点的数据内容，节点创建/修改的事务ID，节点/修改创建时间，当前的数据版本号，数据内容长度，子节点个数等。
ZooKeeper被设计用来存储管理服务的数据：状态信息、配置、位置信息等，所以每个节点存储的数据通常很小，几字节到几K字节不等。默认上限是1M。
zonde维持一个stat结构，它包含数据变化的版本号、ACL变化和时间戳，以允许cache校验和协调化的更新。每当znode的数据变化时，版本号将增加。一个客户端收到数据时，它也会收到数据的版本号。
保存在每个znode中的数据都是自动读写的。读操作获取znode的所有数据，写操作替换掉znode的所有数据。每个节点有一个访问控制表（ACL）来限制谁能做哪些操作。
TIPS 节点大小
配置文件中的jute.maxbuffer属性表示节点可存的数据大小，default=0xfffff=1MB，如果超出该值则会引起ZooKeeper系统不稳定，甚至崩溃，直接重启无效，所以禁止创建数据超过1MB的节点；鉴于超过10k的节点数据对性能的较大影响，建议数据大小尽可能控制在10k之内。
ZooKeeper的一个设计目标是易于编程。所以，它只支持如下操作：
客户端和server间采用长连接。连接建立后，server产生session ID返还给客户端。客户端定期发送pin包来检查和保持和server的连接。一旦session结束或超时，所有ephemeral而节点会被删除。客户端可根据情况设置合适的session超时时间。
Watches是客户端安装在server的事件侦听方法；当侦听的变化发生时，server发消息给客户端进行通知。客户端使用单线程对所有事件按顺序同步回调。每次触发后会被自动删除。如果需要再次侦听事件，必须重新安装Watches。无法保证跟踪到每一个变化，避免安装大量的Watches侦听在同一个节点。Watches的创建和触发规则：所有的API是怎么创建一个Watches，写请求的API，会触发一些事件。举一个例子：当我们调用Watches，我们用一个create，谁创建这个Watches这个节点就会被触发掉。
不参与选举，永远是follower。Observer数量增加，进一步提升集群的服务能力。不会增加重新选举leader的开销。很好地支持跨数据中心、本地读、异地写的功能。
下图从较高层次说明了ZooKeeper的构成
集群数据库是存在于内存中的数据库，保存命名空间的所有数据。更新操作会被记录到硬盘中以便恢复，写操作先被序列化到硬盘中，再应用到内存数据库中。通常ZooKeeper由2n+1台servers组成，只要有n+1台（大多数）server可用，整个系统保持可用。
对于follower收到的client的请求，对于读操作，由follower的本地内存数据库直接给client返回结果；对于会改变系统状态的写操作，则交由Leader进行提议投票，超过半数通过后返回结果给client：
ZooKeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当leader被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。
广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。 当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态。
zk的实现中用了基于paxos算法（主要是fastpaxos）的实现。具体如下：
此外恢复模式下，如果是重新刚从崩溃状态恢复的或者刚启动的的server还会从磁盘快照中恢复数据和会话信息（zk会记录事务日志并定期进行快照，方便在恢复时进行状态恢复）。 选完leader以后，ZooKeeper就进入状态同步过程。
状态同步过程如下：
创建节点性能测试
删除节点性能测试
读取节点内容性能测试
命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等——这些我们都可以统称他们为名字（Name）。其中较为常见的就是一些分布式服务框架中的服务地址列表。通过调用ZK提供的创建节点的API，能够很容易创建一个全局唯一的znode，所有应用从中读取，避免写死。
ZooKeeper中特有watcher注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使用方法通常是不同系统都对ZK上同一个znode进行注册，监听znode的变化（包括znode本身内容及子节点的），其中一个系统update了znode，那么另一个系统能够收到通知，并作出相应处理
这个主要得益于ZooKeeper为我们保证了数据的强一致性。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
简单地讲有两种，一种是常规的先进先出队列，另一种是要等到队列成员聚齐之后的才统一按序执行。对于第一种先进先出队列，和分布式锁服务中的控制时序场景基本原理一致，这里不再赘述。
第二种队列其实是在FIFO队列的基础上作了一个增强。通常可以在 /queue 这个znode下预先建立一个/queue/num 节点，并且赋值为n（或者直接给/queue赋值n），表示队列大小，之后每次有队列成员加入后，就判断下是否已经到达队列大小，决定是否可以开始执行了。这种用法的典型场景是，分布式环境中，一个大任务Task A，需要在很多子任务完成（或条件就绪）情况下才能进行。这个时候，凡是其中一个子任务完成（就绪），那么就去 /taskList 下建立自己的临时时序节点（CreateMode.EPHEMERAL_SEQUENTIAL），当 /taskList 发现自己下面的子节点满足指定个数，就可以进行下一步按序进行处理了。
标签：
原文地址：http://www.cnblogs.com/scott19820130/p/4623262.html
