了解Zookeeper

一、Zookeeper概述

ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。

关于zookeeper 这样的系统功能的讨论都围绕着一条主线：它可以在分布式系统中协作多个任务。一个协作任务是指一个包含多个进程的任务

Zookeeper的设计相比于其它的分布式管理器来说更专注于协作，并不提供锁的接口，或通用数据存储接口。同时，zookeeper没有给开发人员强加任何特殊的同步原语，使用起来非常灵活。

二、Zookeeper基础

1.API

zookeeper并不直接暴漏原语，取而代之的是它暴漏了由一部分调用方法组成的类似文件系统的API。通常使用菜谱(recipes)来表示这些原语的实现。菜谱包括zookeeper操作和维护一个小型的数据节点，这些节点被称为znode.,类似于文件系统的树形结构。

zookeeper 暴露了以下的方法

create /path data   //创建一个名为/path的znode节点，并包含数据data
delete /path //删除名为/path的节点
exist /path  检查是否存在名为/path的节点
setData /path data // 设置名为/path的数据为data
getData /path 返回名为/path节点的数据信息
getChildren /path 返回所有/path节点的所有子节点信息。

当设置一个znode 节点的数据或读取时，znode节点聂荣会被整个替换或者全部读取出来。

2. znode的不同类型

新建znode时还需要指定该节点的类型，不同的类型 决定了znode 的行为模式。
持久节点和临时节点 持久节点只有调用了delete才能删除，临时的znode与之相反，当创建该节点的客户端崩溃了或关闭了zookeeper的连接时，这个节点就会被删除。

有序节点 一个节点可以设置为有序节点，。一个有序节点被分配一个单调递增的整数。当创建有序节点时，一个序号会被追加到路径之后。

3.监视与通知，

zookeeper采用基于通知的机制。客户端通过向zookeeper注册需要接受通知的znode,通过对znode设置监视点来接受通知。监视点是一个单次触发的操作。为了接收多个通知，客户必须在每次通知后设置一个新的监视点。通知机制的一个重要保障是对同一个znode的操作，是先向客户端传送一个通知，然后再对该节点进行变更，这样能保证顺序。

4.版本

每一个znode都有一个版本号，它随着每次数据变化而自增。setData和delete可以有条件的执行。这两个调用以版本号作为传入参数，只有当转入参数的版本号与服务器上的版本号一致时才会调用成功。

三、Zookeeper架构

zookeeper 服务器运行于两种模式之下：独立模式，和仲裁模式。独立模式只有一个单独的服务器，而仲裁迷失有一组服务器，我们称之为zookeeper集合，他们之间可以进行状态的复制，并同时服务于客户端等 请求。

1.zookeeper仲裁

在zookeeper中，法定人数是zookeeper工作必须有效运行的服务器的最小数量。这个数字也是服务器告知客户端安全保存数据前，需要保存客户端数据的服务器的最小个数。
选择法定人数是一个非常重要的事。法定人数的数量需要保证不管系统发生延迟或者崩溃，服务主动确认的任何请求都需要保持下去，直到另一个请求代替。

2. 会话

对zookeeper 执行任何请求前必须要先与服务建立会话。客户端的所有操作均关联在一个会话上，当一个会话因某种原因而终止时，这个会话期间创建的临时节点将会消失。
会话提供了顺序保障，这就意味着同一个会话中的请求会以FIFO顺序执行。通常一个客户端制只打开一个会话，因此客户端请求将全部以FIFO顺序执行。