1，什么是zookeeper
Zookeeper是Google的Chubby一个开源的实现，是hadoop的分布式协调工作 用于名称服务、分组服务、配置信息等等。，它是一个轻量级分布式架构和api实现分布式管理。
2，为什么要用到 zookeeper
1)大部分分布式应用需要一个主控、协调器或者控制来管理物理分布的子进程(如:资源、任务分配等)
2)目前，大部分应用需要开发私有的协调程序，缺乏一个通用的机制
3)协调程序的反复编写浪费，切难以形成通用、伸缩性到的协调器
4)zookeeper ：提供通用的分布式锁服务，用以协调分布式应用
3，zookeeper能帮我们做什么
1)hadoop2.0,使用zookeeper的事件处理确保整个集群只有一个活跃的namenode，存储配置信息等
2)Hbase,使用zookeper的事件处理确保整个集群只有一个HMaster，察觉HRegionServer联机或宕机，存储访问控制列表
3，zookeeper的特性
1）Zookeeper简单和轻量级的
2）Zookeeper是高可用的
3）Zookeeper采用松耦合交互方式
4）zookeeper是一个资源库，他用了存储管理分布式的配置信息
4，zookeeper架构图
5，zookeeper的数据模型
1）层次化的目录结构，命名符号常规文件系统规范
2）每个节点在zookeeper叫做znode，并且其中一个唯一的路径标识
3)节点znode可以包含数据和子节点，但是ephemeral类型的节点不能有字节点（因为他是临时类型）
4)znode中的数据可以有多个版本，比如某个路径下存有多个数据版本，那么查询中国路径下的数据就需要带上版本
5）客户端应用可以在节点上设置观察器
6，zookeeper·的·节点
1）znode有两种类型，临时的(ephemeral)和持久的(persistent)
2) znode类型在创建是确定后不能改变
3）临时znode的客户端会话结束后会自动删除,临时znode不可有子节点
4)持久znode不依赖与客户端会话，只有当客户端明确要删除后才会被删除
5)znode有4中形式的目录节点，persistent(持久节点)，persistent_sequential(持久序列节点)，ephemeral（临时节点），ephemeral_sequential（临时序列节点）后面会介绍他们的使用
7，zookeeper的角色
1）领导者(leader),负责进行投票的发起和决议，更新系统状态
2）学习者(learner),包括跟随者(follower)和观察(observer),folower用于结束客户端请求并向客户端返回结果，在选主过程中参与投票
3）observer可以介绍客户端连接，将写请求转发给leader，但observer不参与投票过程，只有follower参与投票，只同步leader的状态，observer的目录是为了扩展系统，提高读取速度
8，zookeeper的顺序号
1)创建znode是设置顺序的标识，znode名称后会附加一个值叫顺序号
2)顺序号是一个单调递增的计数器，有父节点维护
3）在分布式系统中，顺序号可以被用于为所有的事件进行全局排序，这样客户端可以通过顺序号推断事件的顺序
9.zookeeper的读写机制
1)zookeeper是一个由多个server组成的集群
2)一个leader，多个follower
3)每个server保存一份数据复本
4)全局数据一致
5)分布式读写
6)更新请求转发，由leader实施
10，zookeeper的保证
1)更新请求顺序进行，来自同一个client的更新请求按其发送顺序依次执行
2)数据更新原子性，一次数据要么更新成功，要么失败
3)全局唯一数据视图，client无论连接到哪一个server，数据视图都是一样的
4)实时性，在一定事件范围内，client能读到最新数据
11，观察(watcher)
1）watcher在zookeeper是一个核心功能，watcher可以监控目录节点数据变化以及目录的变化，一旦这些状态发生变化，服务器就会通知所有的设置在这个目录节点上的watcher，从而每个客户端都很快知道他所关注的目录节点的状态发生变化，而做出相应的反应
2)可以触发观察的操作:get ,set ,create
12，ACL(access control list 访问控制列表，权限)
每个znode被创建是都会带有一个acl列表，用于决定可以对他执行何种操作
13,zookeeper的工作原理
1)Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和server具有相同的系统状态。
2）一旦leader已经和多数的follower进行了状态同步后，他就可以开始广播消息了，即进入广播状态。这时候当一个server加入zookeeper服务中，它会在恢复模式下启动，发现leader，并和leader进行状态同步。待到同步结束，它也参与消息广播。Zookeeper服务一直维持在Broadcast状态，直到leader崩溃了或者leader失去了大部分的followers支持
3)广播模式需要保证proposal被按顺序处理，因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。
4)当leader崩溃或者leader失去大多数的follower，这时候zk进入恢复模式，恢复模式需要重新选举出一个新的leader，让所有的server都恢复到一个正确的状态。
14,leader推选过程
1,所有节点在同一path下创建sequential + ephemeral 节点
2，创建了最小序列值得节点就是leader，其他节点就是follower
3，每个节点观察比自己小的最大节点
4，如果leader宕机，则leader节点会被删除
5，观察leader的follower会收到通知，leader被删除了
6，下家follower检查是否有其他节点有着最小序列号，没有自己则是leader，否则创建一个最小序列号节点成为leader
7，所有其他节点都会选择最小号的节点作为leader
15，zookeper的一些简单命令
$zk>create /zk/node1 tom
$zk>create -s /a/b "" // /a/b0000000000==>序列节点
$zk>create -s /a/b "" // /a/b0000000001==>序列节点
$zk>create -e /a/c "" // 临时节点，当前会话有效，会话关闭，节点删除。$zk>get /zk/node1 //取节点数据,查看节点状态
$zk>set /zk/node1 jerry //修改节点的数据
$zk>ls /zk //查看孩子$zk>delete /a //删除空节点
$zk>rmr /a //递归删除节点$zk>stat /a //查看节点状态,不显示数据.
下篇会讲到eclipse操作zookeeper的api