Zookeeper了解及使用

在zookeeper的介绍中,我们经常会看到这样一句话,ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务。可以看出,zookeeper主要是在分布式系统中,对各个子系统起到协调的作用,主要解决分布式环境各个系统数据的一致性问题。

ZooKeeper 实现诸如配置管理,注册中心,数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。

目前在比较流行的应用或框架中都有被用到,像Hadoop、solr、kafka、dubbo中都有用到,可见其在当下环境中,构建集群或微服务环境都是起着举足轻重的作用。

  • 下载及安装

直接在官网下载,地址https://www.apache.org/dyn/closer.cgi/zookeeper/,我们选择下载.tar.gz版本的,这样直接解压就可以使用了。

首先修改下config/zoo_sample.cfg,将其拷贝一份,命名为zoo.cfg即可。一般情况下,我们会修改下数据与日志的存放路径:

dataDir=../data
dataLogDir=../data/log

然后在bin目录下,双击zkServer.cmd,即可启动,如下:

和大多数应用一样,zookeeper也为我们提供了cli方式进行操作。

从中摘取了部分内容,上面提到,zookeeper主要帮助我们保证分布式环境中,协调各个子系统可靠的工作,而zookeeper提供的主要还是数据的存取与监听服务,在这些基础服务的基础上,在各种应用场景下,让它帮助我们完成了更多的功能,比如保证数据的一致性,完成服务的注册发现等,那么这些设计的前提必须要满足几点:

1. 一致性:client不论连接到哪个Server,展示给它都是同一个视图,这是ZooKeeper最重要的性能。
2. 可靠性:具有简单、健壮、良好的性能,如果消息m被到一台服务器接受,那么它将被所有的服务器接受。
3. 实时性:ZooKeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息,或者服务器失效的信息。但由于网络延时等原因,ZooKeeper不能保证两个客户端能同时得到刚更新的数据,如果需要最新数据,应该在读数据之前调用sync()接口。
4. 等待无关(wait-free):慢的或者失效的client不得干预快速的client的请求,使得每个client都能有效的等待。
5. 原子性:更新只能成功或者失败,没有中间状态。
6. 顺序性:包括全局有序和偏序两种:全局有序是指如果在一台服务器上消息a在消息b前发布,则在所有Server上消息a都将在消息b前被发布;偏序是指如果一个消息b在消息a后被同一个发送者发布,a必将排在b前面。

zookeeper是存储结构非常类似于文件系统,每一个目录对应了一个节点(znode),数据都存储在各个节点上,对节点的访问必须是绝对路径,因为每个节点都是唯一的,同时每个节点可以设置访问控制ACL,或者设置watch来监听节点关联数据的变化,节点主要有stat、data、children三个属性,其中stat:

从节点的性质看,一共分为四种类型:

1、临时无序 断开连接则删除,其实是session断开或关闭
2、临时有序 同上,只不过节点由zookeeper进行顺序编号
3、持久无序 持久化的节点在连接断开后依然存在
4、持久有序 同上,只不过节点由zookeeper进行顺序编号
-注意:
临时节点不能有子节点
数据存在节点上,而数据都有版本号的
节点都可以被客户端监听,当出现节点上数据修改、子节点变化,都会进行通知

对节点的操作前提是有对应的ACL权限,在建立节点时,可以设置对该节点有那哪些操作权限,一共有以下这些可选值:

CREATE: 创建子节点的权限。(对子节点)
READ: 获取节点数据和子节点列表的权限。
WRITE:更新节点数据的权限。
DELETE: 删除子节点的权限。(对子节点)
ADMIN: 设置节点ACL的权限。

zookeeper中服务器与客户端间是通过tcp长连接进行通信,在连接成功后会建立两者间的会话(session),之后的请求都是依赖于此,而维持会话的则是通过心跳检查机制。session有以下几个状态:CONNECTING、CONNECTED、RECONNECTING、RECONNECTED、CLOSE等。在每次请求过程中,都会重新激活会话,当然,如果客户端长时间没有与服务器通信,则会在1/3超时时间时通过PING命令维持会话。【参考

一般不会在单机下使用zookeeper,那样可靠性就没了保证,那么在集群环境中,zookeeper是如何保证数据的一致性呢?

首先需要了解,zookeeper集群中会将各个机器分为三个角色:
1、Leader:系统故障时完成数据恢复;保证并维持多台机器的状态一致;发起投票与决策。
    维持服务器间的心跳连接,并接受处理其发送的请求,讲多请求的有序化,保证请求的有序与原子性。
2、Fllower:与Leader通信保存连接;Leader故障参与选举;与客户端通信与数据交互。
    向Leader发送命令(PING消息、REQUEST消息、ACK消息、REVALIDATE消息),处理Leader的命令。
    处理客户端请求,写则交由Leader完成。
3、Observer:类似Fllower,但不参与集群选举与投票。
    对集群的扩展
消息类型:
    PING消息: 心跳消息;
    PROPOSAL消息:Leader发起的提案,要求Follower投票;
    COMMIT消息:服务器端最新一次提案的信息;
    UPTODATE消息:表明同步完成;
    REVALIDATE消息:根据Leader的REVALIDATE结果,关闭待revalidate的session还是允许其接受消息;
    SYNC消息:返回SYNC结果到客户端,这个消息最初由客户端发起,用来强制得到最新的更新。
-

那么zookeeper的具体原理又是怎样的呢?

 1、zookeeper保证数据一致性的关键是ZAB协议,该协议主要完成两点功能,恢复、广播。当Leader出现故障导致崩溃时,出现新的选举,当选举完新的Leader后,会进行状态恢复;而广播模式让Leader与Learner保持状态一致。
2、为了保证事务的顺序一致性,zookeeper采用了递增的事务id号(zxid)来标识事务。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64位的数字,它高32位是epoch用来标识leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch,标识当前属于那个leader的统治时期。低32位用于递增计数
3、每个Server在工作过程中有三种状态:
    LOOKING:当前Server不知道leader是谁,正在搜寻
    LEADING:当前Server即为选举出来的leader
    FOLLOWING:leader已经选举出来,当前Server与之同步
--选举【参考】
  当系统启动或者leader崩溃后,就会开始leader的选举。
    1.状态变更。服务器启动的时候每个server的状态时Looking,如果是leader挂掉后进入选举,那么余下的非Observer的Server就会将自己的服务器状态变更为Looking,然后开始进入Leader的选举状态;
    2.发起投票。每个server会产生一个(sid,zxid)的投票,系统初始化的时候zxid都是0,如果是运行期间,每个server的zxid可能都不同,这取决于最后一次更新的数据。将投票发送给集群中的所有机器;
    3.接收并检查投票。server收到投票后,会先检查是否是本轮投票,是否来自looking状态的server;
    4.处理投票。对自己的投票和接收到的投票进行PK:
        先检查zxid,较大的优先为leader;
        如果zxid一样,sid较大的为leader;
        根据PK结果更新自己的投票,在次发送自己的投票;
    5.统计投票。每次投票后,服务器统计投票信息,如果有过半机器接收到相同的投票,那么leader产生,如果否,那么进行下一轮投票;
    6.改变server状态。一旦确定了Leader,server会更新自己的状态为Following或者是Leading。
    7.选举结束。
说明:
    在步骤2发送投票的时候,投票的信息除了sid和zxid,还有:
        electionEpoch:逻辑时钟,用来判断多个投票是否在同一轮选举周期中,该值在服务端是一个自增序列,每次进入新一轮的投票后,都会对该值进行加1操作。
        peerEpoch:被推举的Leader的epoch。
        state:当前服务器的状态。
    为了能够相互投票,每两台服务器之间都会建立网络连接,为避免重复建立TCP连接,zk的server只允许sid大于自己的服务器与自己建立连接,否则断开当前连接,并主动和对方建立连接。
--请求流程
    1.在Client向Follwer发出一个写的请求
    2.Follwer把请求发送给Leader
    3.Leader接收到以后开始发起投票并通知Follwer进行投票
    4.Follwer把投票结果发送给Leader
    5.Leader将结果汇总后如果需要写入,则开始写入同时把写入操作通知给Leader,然后commit;
    6.Follwer把请求结果返回给Client
--事务一致
    更新请求顺序进行,来自同一个client的更新请求按其发送顺序依次执行。
    数据更新原子性,一次数据更新要么成功,要么失败。
    全局唯一数据视图,client无论连接到哪个server,数据视图都是一致的。
    实时性,在一定事件范围内,client能读到最新数据。
--
  • 应用场景(【参考】)
1、命名服务
2、配置管理
3、集群管理
4、分布式锁
5、队列管理
6、发布订阅
  • 常用命令
conf 输出相关服务配置的详细信息。
cons 列出所有连接到服务器的客户端的完全的连接 / 会话的详细信息。包括“接受 / 发送”的包数量、会话 id 、操作延迟、最后的操作执行等等信息。
dump 列出未经处理的会话和临时节点。
envi 输出关于服务环境的详细信息(区别于 conf 命令)。
reqs 列出未经处理的请求
ruok 测试服务是否处于正确状态。如果确实如此,那么服务返回“imok ”,否则不做任何相应。
stat 输出关于性能和连接的客户端的列表。
wchs 列出服务器 watch 的详细信息。
wchc 通过 session 列出服务器 watch 的详细信息,它的输出是一个与watch 相关的会话的列表。
wchp 通过路径列出服务器 watch 的详细信息。它输出一个与 session相关的路径。
  • ZAB协议与Paxos算法

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券