Zookeeper简单介绍

一、Zookeeper---分布式协调技术

Zookeeper---分布式协调技术，即主要用来解决分布式环境当中多个进程之间的同步控制，让它们有序的去访问某种临界资源，防止造成“脏数据”的后果。

来看下图：

图片中有三台机器，每台机器跑一个应用程序。我们将这三台机器用网络连接起来，构成一个系统来为用户提供服务，

对用户来说这个系统架构透明的，他感觉不到我这个系统是一个什么样的架构，那么我们就可以把这种系统称作为分布式系统。

在这种分布式系统中如何对进程进行调度，我们假设在第一台机器上挂载了一个资源，然后这3个物理分区都要竞争这个资源，

但我们又不希望他们同时进行访问，这时我们就需要一个协调器，来让它们有序的访问这个资源。这个协调器就是我们经常说的锁，

比如说“进程-1”在使用该资源的时候，会先去获得锁，“进程-1”就会对该资源独占，这样其他进程就无法访问该资源，“进程1”用完该

资源后就将锁释放掉，让其他进程来获取锁，那么这个锁机制就保证了分布式系统中多个进程能够有序的访问该资源。我们把这个分

布式环境下的这个锁叫做分布式锁，这个分布式锁也就是我们分布式协调技术实现的核心内容。Zookeeper就是它的实现。Zookeeper

是一种为分布式应用设计的高可用、高性能且一致的开源服务，它提供了一项基本服务：分布式锁服务，它的其他使用方法主要有：

配置维护、组服务、分布式消息列队、分布式通知/协调等

二、Zookeeper能干嘛

  1.配置管理： 

     分布式系统都有好多机器，比如我在搭建hadoop的HDFS的时候，需要在一个主机器上（Master节点）配置好HDFS需要的各种配置文件，然后通过scp命令把这些配置文件拷贝到其他节点上，这样各个机器拿到的配置信息是一致的，才能成功运行起来HDFS服务。Zookeeper提供了这样的一种服务：一种集中管理配置的方法，我们在这个集中的地方修改了配置，所有对这个配置感兴趣的都可以获得变更。这样就省去手动拷贝配置了，还保证了可靠和一致性。 

 2.名字服务

   可以简单理解为一个电话薄，电话号码不好记，但是人名好记，要打谁的电话，直接查人名就好了。 
分布式环境下，经常需要对应用/服务进行统一命名，便于识别不同服务； 
类似于域名与ip之间对应关系，域名容易记住； 
通过名称来获取资源或服务的地址，提供者等信息

 3.分布式锁

  单机程序的各个进程需要对互斥资源进行访问时需要加锁，那分布式程序分布在各个主机上的进程对互斥资源进行访问时也需要加锁。很多分布式系统有多个可服务的窗口，但是在某个时刻只让一个服务去干活，当这台服务出问题的时候锁释放，立即fail over到另外的服务。这在很多分布式系统中都是这么做，这种设计有一个更好听的名字叫Leader Election(leader选举)。举个通俗点的例子，比如银行取钱，有多个窗口，但是呢对你来说，只能有一个窗口对你服务，如果正在对你服务的窗口的柜员突然有急事走了，那咋办？找大堂经理（zookeeper）!大堂经理指定另外的一个窗口继续为你服务！

 4.集成管理

  

在分布式的集群中，经常会由于各种原因，比如硬件故障，软件故障，网络问题，有些节点会进进出出。有新的节点加入进来，也有老的节点退出集群。这个时候，集群中有些机器（比如Master节点）需要感知到这种变化，然后根据这种变化做出对应的决策。我已经知道HDFS中namenode是通过datanode的心跳机制来实现上述感知的，那么我们可以先假设Zookeeper其实也是实现了类似心跳机制的功能吧！

Zookeeper的特点

1 最终一致性：为客户端展示同一视图，这是zookeeper最重要的功能。 
2 可靠性：如果消息被到一台服务器接受，那么它将被所有的服务器接受。 
3 实时性：Zookeeper不能保证两个客户端能同时得到刚更新的数据，如果需要最新数据，应该在读数据之前调用sync()接口。 
4 等待无关（wait-free）：慢的或者失效的client不干预快速的client的请求。 
5 原子性：更新只能成功或者失败，没有中间状态。 
6 顺序性：所有Server，同一消息发布顺序一致。

Zookpeeper的基本架构

 
1 每个Server在内存中存储了一份数据； 
2 Zookeeper启动时，将从实例中选举一个leader（Paxos协议）； 
3 Leader负责处理数据更新等操作（Zab协议）； 
4 一个更新操作成功，当且仅当大多数Server在内存中成功修改 
数据。 

Zookeeper Server数目一般为奇数

 Leader选举算法采用了Paxos协议；Paxos核心思想：当多数Server写成功，则任务数据写 
成功。也就是说： 
如果有3个Server，则两个写成功即可； 
如果有4或5个Server，则三个写成功即可。 
Server数目一般为奇数（3、5、7） 
如果有3个Server，则最多允许1个Server挂掉； 
如果有4个Server，则同样最多允许1个Server挂掉 

Observer节点

3.3.0 以后 版本新增角色Observer 
增加原因： 
Zookeeper需保证高可用和强一致性； 
当集群节点数目逐渐增大为了支持更多的客户端，需要增加更多Server，然而Server增多，投票阶段延迟增大，影响性能。为了权衡伸缩性和高吞吐率，引入Observer： 
Observer不参与投票； 
Observers接受客户端的连接，并将写请求转发给leader节点； 
加入更多Observer节点，提高伸缩性，同时不影响吞吐率。

Zookeeper写流程：

 

客户端首先和一个Server或者Observe（可以认为是一个Server的代理）通信，发起写请求，然后Server将写请求转发给Leader，Leader再将写请求转发给其他Server，Server在接收到写请求后写入数据并相应Leader，Leader在接收到大多数写成功回应后，认为数据写成功，相应Client。

Zookeeper数据模型

 
zookeeper采用层次化的目录结构，命名符合常规文件系统规范； 
每个目录在zookeeper中叫做znode,并且其有一个唯一的路径标识； 
Znode可以包含数据和子znode（ephemeral类型的节点不能有子znode）； 
Znode中的数据可以有多个版本，比如某一个znode下存有多个数据版本，那么查询这个路径下的数据需带上版本； 
客户端应用可以在znode上设置监视器（Watcher） 
znode不支持部分读写，而是一次性完整读写 
Znode有两种类型，短暂的（ephemeral）和持久的（persistent）； 
Znode的类型在创建时确定并且之后不能再修改； 
ephemeralzn ode的客户端会话结束时，zookeeper会将该ephemeral znode删除，ephemeralzn ode不可以有子节点； 
persistent znode不依赖于客户端会话，只有当客户端明确要删除该persistent znode时才会被删除； 
Znode有四种形式的目录节点，PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、PHEMERAL_SEQUENTIAL。