Zookeeper知识点整理

基础篇

一、zookeeper是什么
Zookeeper,一种分布式应用的协做服务,是Google的Chubby一个开源的实现,是Hadoop的分布式协调服务,它包含一个简单的原语集,应用于分布式应用的协做服务,使得分布式应用能够基于这些接口实现诸如同步、配置维护和分集群或者命名的服务。

zookeeper是一个由多个service组成的集群,一个leader,多个follower,每一个server保存一份数据部分,全局数据一致,分布式读写,更新请求转发由leader实施.

更新请求顺序进行,来自同一个client的更新请求按其发送顺序依次执行,数据更新原子性,一次数据更新要么成功,要么失败,全局惟一数据试图,client不管链接到哪一个server,数据试图是一致的.

二、为何要用zookeeper
大部分分布式应用须要一个主控、协调器或控制器来管理物理分布的子进程（如资源、任务分配等）,目前,大部分应用须要开发私有的协调程序,缺少一个通用的机制.协调程序的反复编写浪费,且难以造成通用、伸缩性好的协调器,ZooKeeper：提供通用的分布式锁服务,用以协调分布式应用

三、zookeeper工做原理
zookeeper的核心是原子广播,这个机制保证了各个server之间的同步,实现这个机制的协议叫作Zab协议.Zab协议有两种模式,他们分别是恢复模式和广播模式.

　 （1）当服务启动或者在领导者崩溃后,Zab就进入了恢复模式,当领导着被选举出来,且大多数server都完成了和leader的状态同步后,恢复模式就结束了.状态同步保证了leader和server具备相同的系统状态.

　 （2）一旦leader已经和多数的follower进行了状态同步后,他就能够开始广播消息了,即进入广播状态.这时候当一个server加入zookeeper服务中,它会在恢复模式下启动,发下leader,并和leader进行状态同步,待到同步结束,它也参与广播消息.

说明:

广播模式须要保证proposal被按顺序处理,所以zk采用了递增的事务id号(zxid)来保证.全部的提议(proposal)都在被提出的时候加上了zxid.实现中zxid是一个64为的数字,它高32位是epoch用来标识leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch.低32位是个递增计数.

当leader崩溃或者leader失去大多数的follower,这时候zk进入恢复模式,恢复模式须要从新选举出一个新的leader,让全部的server都恢复到一个正确的状态.

zookeeper服务一致维持在Broadcast状态,直到leader崩溃了或者leader失去了大部分的followers支持.

Broadcast模式极其相似于分布式事务中的2pc（two-phrase commit 两阶段提交）：即leader提起一个决议,由followers进行投票,leader对投票结果进行计算决定是否经过该决议,若是经过执行该决议（事务）,不然什么也不作.

三、Leader选举
每一个Server启动之后都询问其它的Server它要投票给谁,对于其余server的询问,server每次根据本身的状态都回复本身推荐的leader的id和上一次处理事务的zxid（系统启动时每一个server都会推荐本身）,收到全部Server回复之后,就计算出zxid最大的哪一个Server,并将这个Server相关信息设置成下一次要投票的Server.计算这过程当中得到票数最多的的sever为获胜者,若是获胜者的票数超过半数,则改server被选为leader.不然,继续这个过程,直到leader被选举出来.leader就会开始等待server链接,Follower链接leader,将最大的zxid发送给leader,Leader根据follower的zxid肯定同步点,完成同步后通知follower 已经成为uptodate状态,Follower收到uptodate消息后,又能够从新接受client的请求进行服务了.

四、zookeeper的数据模型
层次化的目录结构,命名符合常规文件系统规范
每一个节点在zookeeper中叫作znode,而且其有一个惟一的路径标识
节点Znode能够包含数据和子节点,可是EPHEMERAL类型的节点不能有子节点
Znode中的数据能够有多个版本,好比某一个路径下存有多个数据版本,那么查询这个路径下的数据就须要带上版本
客户端应用能够在节点上设置监视器,节点不支持部分读写,而是一次性完整读写

Zoopkeeper 提供了一套很好的分布式集群管理的机制,就是它这种基于层次型的目录树的数据结构,并对树中的节点进行有效管理,从而能够设计出多种多样的分布式的数据管理模型

五、Zookeeper的节点
Znode有两种类型,短暂的（ephemeral）和持久的（persistent）
Znode的类型在建立时肯定而且以后不能再修改
短暂znode的客户端会话结束时,zookeeper会将该短暂znode删除,短暂znode不能够有子节点
持久znode不依赖于客户端会话,只有当客户端明确要删除该持久znode时才会被删除
Znode有四种形式的目录节点,PERSISTENT、PERSISTENT_SEQUENTIAL、EPHEMERAL、EPHEMERAL_SEQUENTIAL.

znode 能够被监控,包括这个目录节点中存储的数据的修改,子节点目录的变化等,一旦变化能够通知设置监控的客户端,这个功能是zookeeper对于应用最重要的特性,经过这个特性能够实现的功能包括配置的集中管理,集群管理,分布式锁等等.

六、Zookeeper的角色
（1）领导者（leader）：负责进行投票的发起和决议,更新系统状态
（2）学习者（learner）：包括跟随者（follower）和观察者（observer）.
a、follower用于接受客户端请求并想客户端返回结果,在选主过程当中参与投票
b、Observer能够接受客户端链接,将写请求转发给leader,但observer不参加投票过程,只同步leader的状态,observer的目的是为了扩展系统,提升读取速度
（3）客户端（client）,请求发起方

Watcher

Watcher 在 ZooKeeper 是一个核心功能,Watcher 能够监控目录节点的数据变化以及子目录的变化,一旦这些状态发生变化,服务器就会通知全部设置在这个目录节点上的 Watcher,从而每一个客户端都很快知道它所关注的目录节点的状态发生变化,而作出相应的反应

能够设置观察的操做：exists,getChildren,getData

能够触发观察的操做：create,delete,setData

znode以某种方式发生变化时,“观察”（watch）机制可让客户端获得通知.

能够针对ZooKeeper服务的“操做”来设置观察,该服务的其余 操做能够触发观察.

好比,客户端能够对某个客户端调用exists操做,同时在它上面设置一个观察,若是此时这个znode不存在,则exists返回 false,若是一段时间以后,这个znode被其余客户端建立,则这个观察会被触发,以前的那个客户端就会获得通知.

七、Zookeeper集群搭建

Zookeeper 不只能够单机提供服务,同时也支持多机组成集群来提供服务,实际上Zookeeper还支持另一种伪集群的方式,也就是能够在一台物理机上运行多个Zookeeper实例.

Zookeeper经过复制来实现高可用性,只要集合体中半数以上的机器处于可用状态,它就可以保证服务继续。

命令篇

• 链接远程Server：zkCli.sh –server <ip>:<port>
  好比链接到本地Zoopker服务： ./zkCli.sh -server localhost:2181
• 查看节点数据：ls <path>，好比ls / 则查看根目录节点数据
• 查看某个服务Service的提供者
  ls 服务名/providers
• 查看节点数据并能看到更新次数等数据：ls2 <path>，输出字段含义以下：
  cZxid：建立节点的事务id
  ctime：建立节点的时间
  mZxid：修改节点的事务id
  mtime：修改节点的时间
  pZxid：子节点列表最后一次修改的事务id。删除或添加子节点，不包含修改子节点的数据
  cversion：子节点的版本号，删除或添加子节点，版本号会自增
  dataVersion：节点数据版本号，数据写入操做，版本号会递增
  aclVersion：节点ACL权限版本，权限写入操做，版本号会递增
  ephemeralOwner：临时节点建立时的事务id，若是节点是永久节点，则它的值为0
  dataLength：节点数据长度（单位：byte），中文占3个byte
  numChildren：子节点数量
• 建立节点：create <path> <data>
• 获取节点，包含数据和更新次数等数据：get <path>
• 修改节点：set <path> <data>
• 删除节点：delete <path>，若是有子节点存在则删除失败

配置篇

一、zoo.cfx文件解析：
假设以下配置：

#zookeeper-3.4.6-node1的配置
tickTime=2000
initLimit=10
syncLimit=5
clientPort=2181
dataDir=/export/search/zookeeper-cluster/zookeeper-3.4.6-node1/data
server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889

解析：
tickTime=2000:
tickTime这个时间是做为Zookeeper服务器之间或客户端与服务器之间维持心跳的时间间隔,也就是每一个tickTime时间就会发送一个心跳；

initLimit=10:
initLimit这个配置项是用来配置Zookeeper接受客户端（这里所说的客户端不是用户链接Zookeeper服务器的客户端,而是Zookeeper服务器集群中链接到Leader的Follower 服务器）初始化链接时最长能忍受多少个心跳时间间隔数。
当已经超过10个心跳的时间（也就是tickTime）长度后 Zookeeper 服务器尚未收到客户端的返回信息,那么代表这个客户端链接失败。总的时间长度就是 10*2000=20 秒；

syncLimit=5:
syncLimit这个配置项标识Leader与Follower之间发送消息,请求和应答时间长度,最长不能超过多少个tickTime的时间长度,总的时间长度就是5*2000=10秒；

dataDir=/export/search/zookeeper-cluster/zookeeper-3.4.6-node1/data
dataDir顾名思义就是Zookeeper保存数据的目录,默认状况下Zookeeper将写数据的日志文件也保存在这个目录里；

clientPort=2181
clientPort这个端口就是客户端链接Zookeeper服务器的端口,Zookeeper会监听这个端口接受客户端的访问请求；

server.1=localhost:2887:3887
server.2=localhost:2888:3888
server.3=localhost:2889:3889
server.A=B：C：D：
A是一个数字,表示这个是第几号服务器,B是这个服务器的ip地址
C第一个端口用来集群成员的信息交换,表示的是这个服务器与集群中的Leader服务器交换信息的端口
D是在leader挂掉时专门用来进行选举leader所用

参考：https://www.cnblogs.com/denni...