小白大数据工程师的养成之路3 关于zookeeper

最新推荐文章于 2021-06-10 08:39:02 发布

佳减乘除。

最新推荐文章于 2021-06-10 08:39:02 发布

阅读量401

点赞数

分类专栏：大数据ZooKeeper 大数据工程师的养成

本文链接：https://blog.csdn.net/qq_42744710/article/details/81503458

版权

大数据工程师的养成同时被 2 个专栏收录

4 篇文章 0 订阅

订阅专栏

大数据ZooKeeper

1 篇文章 0 订阅

订阅专栏

Zookeeper集群的安装部署

Zookeeper分布式协调简单介绍

主要用来解决分布式环境当中多个进程之间的同步控制，让他们有序的去访问某种临界资源，防止造成"脏数据"的后果

上图是分布式系统

分析一波

每台机器各跑一个应用程序。

然后我们将这三台机器通过网络将其连接起来，构成一个系统来为用户提供服务，对用户来说这个系统的架构是透明的，

那么我们就可以把这种系统称作一个分布式系统。

然后挂一个资源在server1上，三个物理分布都要竞争这个资源

但是又不希望同时进行，则出现了协调器，有了协调器就可以让三个物理分布有序访问这个资源

这个协调器就是所谓的锁可以保证一个进程独占绝对的资源，用完后再释放锁，让其他资源来获得锁。

这样的就叫做分布式锁

分布式锁是分布式协调技术实现的核心内容

实现这些的也就是开发出来的Zookeeper

ZooKeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务

它提供了一项基本服务：分布式锁服务。

由于ZooKeeper的开源特性，后来我们的开发者在分布式锁的基础上，摸索了出了其他的使用方法：配置维护、组服务、分布式消息队列、分布式通知/协调等。

ZooKeeper不会因为一个节点的错误而崩溃

ZooKeeper中有一种新的数据结构 Znode 然后在该数据结构上定义了一些原语

还需要一个通知机制 Watcher机制

所以ZooKeeper所提供的主要服务是：数据结构+原语+watcher机制

Zookeeper数据结构、命令

ZooKeeper的数据模型都是采用树型层次结构

ZooKeeper树中的每个节点被称为—Znode。

ZNode 是 Zookeeper 中最小数据单位

ZooKeeper树中的每个节点可以拥有子节点

在 ZNode 下面又可以再挂 ZNode，这样一层层下去就形成了一个层次化命名空间 ZNode 树，我们称为 ZNode Tree。

Zookeeper 节点类型可以分为三大类：

持久性节点（Persistent）

临时性节点（Ephemeral）

顺序性节点（Sequential）

现实开发中在创建节点的时候通过组合可以生成以下四种节点类型：

持久节点：持久节点就是节点被创建后会一直存在服务器，直到删除操作主动清除

持久顺序节点：持久顺序节点就是有顺序的持久节点。顺序特性实质是在创建节点的时候，会在节点名后面加上一个数字后缀，来表示其顺序

临时节点：时节点就是会被自动清理掉的节点，它的生命周期和客户端会话绑在一起，客户端会话结束，节点会被删除掉。与持久性节点不同的是，临时节点不能创建子节点

临时顺序节点：临时书序节点就是有顺序的临时节点，和持久顺序节点相同，在其创建的时候会在名字后面加上数字后缀。

ZNode 的数据结构是怎么样的呢?

我们看看结构图

整个 ZNode 节点内容包括两部分：节点数据内容和节点状态信息。图中 app1 是数据内容，其他的属于状态信息。那么这些状态信息都有什么含义呢？

cZxid 就是 Create ZXID，表示节点被创建时的事务 ID。

mZxid 就是 Modified ZXID，表示节点最后一次被修改时的事务 ID。

ctime 就是 Create Time，表示节点创建时间。

mtime 就是 Modified Time，表示节点最后一次被修改的时间。

pZxid 表示该节点的子节点列表最后一次被修改时的事务 ID。只有子节点列表变更才会更新 pZxid，子节点内容变更不会更新。

cversion 表示子节点的版本号。

dataVersion 表示内容版本号。

dataLength 表示数据长度。

numChildren 表示子节点数。

ephemeralOwner 表示创建该临时节点时的会话 sessionID，如果是持久性节点那么值为 0。

二、【操作命令】

通过 Help 命令我们看到 Zookeeper 提供很多的操作命令，我们不去一一介绍，选几个我们经常用的吧。

get path [watch] 命令

path 是路径 [watch] 是监视器,一般我们用 API 编程的时候，在 getData、exists、getChildren 时候会自己去实现一个 watcher，或者用默认的 watcher。在这里 get 命令的用法可以默认 watch 就好了，例如 get /app1。如下图：

大家注意 dataVersion = 0，这个是数据内容的版本号，Zookeeper 保证一致性，基本上都会有个版本控制。

set path data [version] 命令

path 是路径 data 是数据内容 [version] 是版本号，我们可以通过 set /app1 newapp1 来更新节点 /app1 的内容，也可以自己设置版本号，不过通过命令行去设置版本号通过 set /app1 newapp1 2。

如下图：

大家可以发现 dataVersion = 1，版本号默认加 1。

delete path [version] 命令

path 是节点路径 [version] 版本号，如下图：

我们再去 get 看看

Node does not exists：/app1，app1 节点不存在了。

create [-s] [-e] path data acl 命令

这个命令后面的参数比较多，[-s] 顺序节点，[-e] 临时性节点，path 路径，data 数据内容，acl 权限。我们创建一个持久性节点。

大家发现没有，节点名后面加上了一串数字，这个就是 Zookeeper 顺序标识。而且是持久性节点。

临时性节点 app2，关闭客户端会话断开会自动清除。

以上内容来自https://www.cnblogs.com/xums/p/7074008.html

zookeeper的作用：

zookeeper是一个分布式应用程序协调服务、开源的组件，有分布式服务的基本都可以用zookeeper。

zookeeper有三种角色的节点，分别是Leader（领导者）、Follower（跟随者）、Observer（观察者）。

Leader 负责更新系统状态，进行投票（选举leader）的发起和决议。

Follower 用于接收客户端请求并向客户端返回处理请求的结果，在选举过程中参与投票 Observer 可以接收客户端的连接，将写请求转发给Leader系诶的那，但Observer不参加投票过程，只同步Leader的状态。

Observer的目的是为了扩展系统，提高读取速度。

zookeeper节点有四种状态，Looking、Following、Leading、Observing

Looking：寻找Leader状态，当Server处于该状态时，此Server会认为当前集群中没有Leader，需要进入Leader选举状态。

Following：跟随者状态，表明该Server角色为Follower。

Leading：领导者状态，表明当前服务器角色是Leader。

Observing：观察者状态，表明当前服务器角色是Observer。

zookeeper的选举机制

    为什么要进行Leader选举？

    Leader主要作用是保证分布式数据一致性，即每个节点的存储的数据同步。遇到以下两种情况需要进行Leader选举

    1）服务器初始化启动

    2）服务器运行期间无法和Leader保持连接，Leader节点崩溃，逻辑时钟崩溃。

    1.服务器初始化时Leader选举

    zookeeper由于其自身的性质，一般建议选取奇数个节点进行搭建分布式服务器集群。以3个节点组成的服务器集群为例，说明服务器初始化时的选举过程。启动第一台安装zookeeper的节点时，无法单独进行选举，启动第二台时，两节点之间进行通信，开始选举Leader。

    1）每个Server投出一票。他们两都选自己为Leader，投票的内容为（SID，ZXID）。SID即Server的id，安装zookeeper时配置文件中所配置的myid；ZXID，事务id，为节点的更新程度，ZXID越大，代表Server对Znode的操作越新。由于服务器初始化，每个Sever上的Znode为0，所以Server1投的票为（1,0），Server2为（2,0）。两Server将各自投票发给集群中其他机器。

    2）每个Server接收来自其他Server的投票。集群中的每个Server先判断投票有效性，如检查是不是本轮的投票，是不是来Looking状态的服务器投的票。

    3）对投票结果进行处理。先了解下处理规则
     - 首先对比ZXID。ZXID大的服务器优先作为Leader
     - 若ZXID相同，比如初始化的时候，每个Server的ZXID都为0，就会比较myid，myid大的选出来做Leader。

    对于Server而言，他接受到的投票为（2,0），因为自身的票为（1,0），所以此时它会选举Server2为Leader，将自己的更新为（2,0）。而Server2收到的投票为Server1的（1,0）由于比他自己小，Server2的投票不变。Server1和Server2再次将票投出，投出的票都为（2,0）。

    4） 统计投票。每次投票之后，服务器都会统计投票信息，如果判定某个Server有过半的票数投它，那么该Server将会作为Leader。对于Server1和Server2而言,统计出已经有两台机器接收了（2,0）的投票信息，此时认为选出了Leader。

    5）改变服务器状态。当确定了Leader之后，每个Server更新自己的状态，Leader将状态更新为Leading，Follower将状态更新为Following。

    2.服务器运行期间的Leader选举

    zookeeper运行期间，如果有新的Server加入，或者非Leader的Server宕机，那么Leader将会同步数据到新Server或者寻找其他备用Server替代宕机的Server。若Leader宕机，此时集群暂停对外服务，开始在内部选举新的Leader。假设当前集群中有Server1、Server2、Server3三台服务器，Server2为当前集群的Leader，由于意外情况，Server2宕机了，便开始进入选举状态。过程如下

    1） 变更状态。其他的非Observer服务器将自己的状态改变为Looking，开始进入Leader选举。

    2） 每个Server发出一个投票（myid，ZXID），由于此集群已经运行过，所以每个Server上的ZXID可能不同。假设Server1的ZXID为145，Server3的为122，第一轮投票中，Server1和Server3都投自己，票分别为（1，145）、（3,122）,将自己的票发送给集群中所有机器。

    3） 每个Server接收接收来自其他Server的投票，降下来的步骤与启动时步骤相同。

由此传送门来哟https://blog.csdn.net/weixin_40083942/article/details/78484099