• Python大数据之linux学习总结——day11_ZooKeeper


    ZooKeeper

    ZK概述

    ZooKeeper概念: Zookeeper是一个分布式协调服务的开源框架。本质上是一个分布式的小文件存储系统
    ZooKeeper作用: 主要用来解决分布式集群中应用系统的一致性问题。
    ZooKeeper结构: 采用树形层次结构,ZooKeeper树中的每个节点被称为—Znode。且树中的每个节点可以拥有子节点
    
    • 1
    • 2
    • 3

    在这里插入图片描述

    ZK集群环境

    在这里插入图片描述

    zookeeper概念: 分布式协调服务
    
    zookeeper的服务角色分别为:
        leader: 管理者 ,负责管理follower,处理所有的事务请求(数据的保存,修改,删除)
        follower: 追随者,负责选举(选举leader)和数据的同步及获取
        observer: 观察者,负责数据的同步及获取(需要在配置文件中指定才能生效)
        
    zookeeper应用: 搭建hadoop高可用环境时,至少需要两个hadoop服务(NameNode和ResourceManager),一主一备,主服务对外提供业务功能,备用服务等待主服务不可用时,启用备用服务器对外提供业务功能    
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8

    ZK启动和使用

    配置环境变量

    配置zookeeper环境变量**(注意三台都单独配置!!!)**

    可以使用CRT客户端发送以下命令到三台

    [root@nodex ~]# echo 'export ZOOKEEPER_HOME=/export/server/zookeeper' >> /etc/profile
    [root@nodex ~]# echo 'export PATH=$PATH:$ZOOKEEPER_HOME/bin' >> /etc/profile
    [root@nodex ~]# source /etc/profile
    
    • 1
    • 2
    • 3

    启动集群

    启动zookeeper服务**(注意三台都单独需要启动!!!)**

    可以使用CRT客户端发送以下命令到三台

    [root@nodex ~]# zkServer.sh start
    
    • 1

    还可以查看服务状态: [root@node]# zkServer.sh status

    关闭zk服务的命令是: [root@node]# zkServer.sh stop

    客户端连接

    连接服务
    方式1:直接连接本地: [root@node1 ~]# zkCli.sh
    方式2:连接其他节点: [root@node1 ~]# zkCli.sh -server 节点地址

    [root@node1 ~]# zkCli.sh
    
    • 1

    ZK的shell命令

    知识点:
    查看所有shell命令: help
    
    create [-s] [-e] 节点绝对路径 节点数据: 创建数据节点    注意: -s代表序列化节点    -e代表临时节点
    
    delete 节点绝对路径 [version]: 删除一级节点  注意: 此方式如果有子节点是不能删除的
    rmr 节点绝对路径: 删多层除节点(如果有子节点也可以删除)
    
    set 节点绝对路径 data [version]: 设置 /修改节点数据
    
    get 节点绝对路径 [watch]: 获取数据    注意: watch是监听
    ls 节点绝对路径  : 查看节点信息        举例: 查看根路径下节点   ls /
    ls2 节点绝对路径 : 查看节点详情信息
    history: 查看操作历史
    
    quit: 退出
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    示例:
    [root@node1 ~]# zkCli.sh
    ...
    WatchedEvent state:SyncConnected type:None path:null
    [zk: localhost:2181(CONNECTED) 0] ls /
    [zookeeper]
    [zk: localhost:2181(CONNECTED) 1] create /binzi 666
    Created /binzi
    [zk: localhost:2181(CONNECTED) 2] create /binzi/b1 111
    Created /binzi/b1
    [zk: localhost:2181(CONNECTED) 3] create /binzi/b2 222
    Created /binzi/b2
    
    [zk: localhost:2181(CONNECTED) 4] ls /
    [binzi, zookeeper]
    [zk: localhost:2181(CONNECTED) 5] ls /binzi
    [b2, b1]
    [zk: localhost:2181(CONNECTED) 6] set /binzi 888
    ...
    [zk: localhost:2181(CONNECTED) 7] get /binzi
    888
    ...
    
    [zk: localhost:2181(CONNECTED) 8] delete /binzi/b1
    [zk: localhost:2181(CONNECTED) 9] ls /binzi
    [b2]
    
    # 注意: delete不能删除有子节点的节点
    [zk: localhost:2181(CONNECTED) 10] delete /binzi
    Node not empty: /binzi 
    # rmr可以删除多层节点
    [zk: localhost:2181(CONNECTED) 11] rmr /binzi
    [zk: localhost:2181(CONNECTED) 12] ls /
    [zookeeper]
    
    [zk: localhost:2181(CONNECTED) 13] history
    ...
    [zk: localhost:2181(CONNECTED) 14] quit
    Quitting...shut down
    [root@node1 ~]# 
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18
    • 19
    • 20
    • 21
    • 22
    • 23
    • 24
    • 25
    • 26
    • 27
    • 28
    • 29
    • 30
    • 31
    • 32
    • 33
    • 34
    • 35
    • 36
    • 37
    • 38
    • 39

    ZK的节点特性和分类

    节点特性

    ZooKeeper的数据模型,在结构上和标准文件系统的非常相似,都是采用树形层次结构,和文件系统的目录树一样,ZooKeeper树中的每个节点可以拥有子节点。
    但也有不同之处:
    
    Znode兼具文件和目录两种特点: Znode没有文件和目录之分,Znode既有像文件一样存储数据,也能像目录一样作为路径标识的一部分
    
    Znode具有原子性操作: 读操作将获取与节点相关的所有数据,写操作也将替换掉节点的所有数据
    
    Znode存储数据大小有限制: 每个Znode的数据大小至多1M,当时常规使用中应该远小于此值
    
    Znode通过路径引用: 路径必须是绝对的,因此他们必须由斜杠字符来开头。除此以外,他们必须是唯一的,也就是说每一个路径只有一个表示,因此这些路径不能改变。  默认有/zookeeper节点用以保存关键的管理信息。
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10

    节点分类

    节点分类: 永久普通节点,临时普通节点,永久序列化节点,临时序列化节点
    
    创建永久普通节点:  create /节点 数据
    
    创建临时普通节点:  create -e /节点 数据
    
    创建永久序列化节点: create -s /节点 数据
    
    创建临时序列化节点: create -e -s /节点 数据
    
    注意: 临时节点不能创建子节点
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11

    节点属性

    每个znode都包含了一系列的属性,通过命令get /节点,可以获得节点的属性
    注意: 对于zk来说,每次的变化都会产生一个唯一的事务id,zxid(ZooKeeper Transaction Id)。通过zxid,可以确定更新操作的先后顺序。例如,如果zxid1小于zxid2,说明zxid1操作先于zxid2发生,zxid对于整个zk都是唯一的,即使操作的是不同的znode。
    cZxid :Znode创建的事务id。
    ctime :Znode创建时的时间戳.

    ​ mZxid :Znode被修改的事务id,即每次对当前znode的修改都会更新mZxid。
    ​ mtime :Znode最新一次更新发生时的时间戳.

    ​ pZxid :Znode的子节点列表变更的事务ID,添加子节点或删除子节点就会影响子节点列表
    ​ cversion :子节点进行变更的版本号。添加子节点或删除子节点就会影响子节点版本号

    ​ dataVersion:数据版本号,每次对节点进行set操作,dataVersion的值都会增加1(即使设置的是相同的数据),可有效避免了 数据更新时出现的先后顺序问题。
    ​ aclVersion : 权限变化列表版本 access control list Version
    ephemeralOwner : 字面翻译临时节点拥有者,永久节点值为: 0x0,临时节点值为:会话ID (不是0x0的就是临时节点)
    ​ dataLength : Znode数据长度
    ​ numChildren: 当前Znode子节点数量(不包括子子节点)

    ZK集群特点

    1. 全局数据一致: 集群中每个服务器保存一份相同的数据副本,client无论连接到哪个服务器,展示的数据都是一致的,这是最重要的特征;
    
    2. 可靠性: 如果消息被其中一台服务器接受,那么将被所有的服务器接受。
    
    3. 顺序性: 包括全局有序和偏序两种:全局有序是指如果在一台服务器上消息a在消息b前发布,则在所有Server上消息a都将在消息b前被发布;偏序是指如果一个消息b在消息a后被同一个发送者发布,a必将排在b前面。
    
    4. 数据更新原子性: 一次数据更新要么成功(半数以上节点成功),要么失败,不存在中间状态;
    
    5. 实时性: Zookeeper保证客户端将在一个时间间隔范围内获得服务器的更新信息,或者服务器失效的信息。
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9

    watch监听机制

    ​ ZooKeeper中,引入了Watcher机制来实现数据发布/订阅功能,一个典型的发布/订阅模型系统定义了一种一对多的订阅关系,能让多个订阅者同时监听某一个主题对象,当这个主题对象自身状态变化时,会通知所有订阅者,使他们能够做出相应的处理。
    ZooKeeper允许客户端向服务端注册一个Watcher监听,当服务端的一些事件触发了这个Watcher,那么就会向指定客户端发送一个事件通知来实现分布式的通知功能。

    watch监听机制过程: 客户端向服务端注册Watcher     服务端事件发生触发Watcher     客户端回调Watcher得到触发事件情况
    Watch监听机制注册格式:  get /节点绝对路径 watch
    Watch监听机制特点:
        先注册再触发: Zookeeper中的watch机制,必须客户端先去服务端注册监听,这样事件发送才会触发监听,通知给客户端
        一次性触发: 事件发生触发监听,一个watcher event就会被发送到设置监听的客户端,这种效果是一次性的,后续再次发生同样的事件,不会再次触发。
        异步发送: watcher的通知事件从服务端发送到客户端是异步的。
        通知内容: 通知状态(keeperState),事件类型(EventType)和节点路径(path)
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7

    示例

    node1上创建临时节点

    [zk: localhost:2181(CONNECTED) 1] create -e /master 1111
    Created /master
    
    • 1
    • 2

    node2上设置监听

    [zk: localhost:2181(CONNECTED) 28] get /master watch
    
    • 1

    node1退出

    [zk: localhost:2181(CONNECTED) 2] quit
    
    • 1

    node2查看消息

    [zk: localhost:2181(CONNECTED) 29] 
    WATCHER::
    
    WatchedEvent state:SyncConnected type:NodeDeleted path:/master
    
    • 1
    • 2
    • 3
    • 4

    ZK应用

    1. 数据发布/订阅
    
    数据发布/订阅系统,就是发布者将数据发布到ZooKeeper的一个节点上,提供订阅者进行数据订阅,从而实现动态更新数据的目的,实现配置信息的集中式管理和数据的动态更新。
    
    主要用到知识点: 监听机制
    
    2. 提供集群选举
    
    在分布式环境下,不管是主从架构集群,还是主备架构集群,要求在服务的时候有且有一个正常的对外提供服务,我们称之为master。
    当master出现故障之后,需要重新选举出的新的master。保证服务的连续可用性。zookeeper可以提供这样的功能服务。
    主要用到知识点: znode唯一性、临时节点短暂性、监听机制。
    
    选举概述: 
    选举要求: 过半原则,所以搭建集群一般奇数,只要某个node节点票数过半立刻成为leader
    
    集群第一次启动: 启动follower每次投票后,他们会相互同步投票情况,如果票数相同,谁的myid大,谁就当选leader,一旦确定了leader,后面来的默认就是follower,即使它的myid大,leader也不会改变(除非leader宕机了)
    
    leader宕机后启动: 每一个leader当老大的时候,都会产生新纪元epoch,且每次操作完节点数据都会更新事务id(高32位_低32位) ,当leader宕机后,剩下的follower就会综合考虑几个因素选出最新的leader,先比较最后一次更新数据事务id(高32位_低32位),谁的事务id最大,谁就当选leader,如果更新数据的事务id都相同的情况下,就需要再次考虑myid,谁的myid大,谁就当选leader
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14
    • 15
    • 16
    • 17
    • 18

    hadoop高可用(主备切换)

    概述

    ​ hadoop2.x之后,Cloudera提出了QJM/Qurom Journal Manager,这是一个基于Paxos算法(分布式一致性算法)实现的HDFS HA方案,它给出了一种较好的解决思路和方案,QJM主要优势如下:不需要配置额外的高共享存储,降低了复杂度和维护成本。消除spof(单点故障)。系统鲁棒性(Robust)的程度可配置、可扩展。

    ​ 在HA架构里面SecondaryNameNode已经不存在了,为了保持standby NN, 实时的与Active NN的元数据保持一致,他们之间交互通过JournalNode进行操作同步。

    ​ 任何修改操作在 Active NN上执行时,JournalNode进程同时也会记录修改log到至少半数以上的JN中,这时 Standby NN 监测到JN 里面的同步log发生变化了会读取 JN 里面的修改log,然后同步到自己的目录镜像文件里面

    ​ 当发生故障时,Active的 NN 挂掉后,Standby NN 会在它成为Active NN 前,读取所有的JN里面的修改日志,这样就能高可靠的保证与挂掉的NN的目录镜像文件一致,然后无缝的接替它的职责,维护来自客户端请求,从而达到一个高可用的目的。

    ​ 在HA模式下,datanode需要确保同一时间有且只有一个NN能命令DN。为此:每个NN改变状态的时候,向DN发送自己的状态和一个序列号。

    ​ DN在运行过程中维护此序列号,当failover时,新的NN在返回DN心跳时会返回自己的active状态和一个更大的序列号。DN接收到这个返回则认为该NN为新的active。

    ​ 如果这时原来的active NN恢复,返回给DN的心跳信息包含active状态和原来的序列号,这时DN就会拒绝这个NN的命令。

    Failover Controller
    HA模式下,会将FailoverController部署在每个NameNode的节点上,作为一个单独的进程用来监视NN的健康状态。

    FailoverController主要包括三个组件:
    HealthMonitor: 监控NameNode是否处于unavailable或unhealthy状态。当前通过RPC调用NN相应的方法完成。

    ​ ActiveStandbyElector: 监控NN在ZK中的状态。

    ​ ZKFailoverController: 订阅HealthMonitor 和ActiveStandbyElector 的事件,并管理NN的状态,另外zkfc还
    负责解决fencing(也就是脑裂问题)。

    JournalNode进程作用: 任何修改操作在 Active NN上执行时,JournalNode进程同时也会记录修改log到至少半数以上的JN中,这时 Standby NN 监测到JN 里面的同步log发生变化了会读取 JN 里面的修改log,然后同步到自己的目录镜像文件里面
    
    DFSZKFailoverController进程作用: 1. 健康监测:周期性的向它监控的NN发送健康探测命令,从而来确定某个NameNode是否处于健康状态,如果机器宕机,心跳失败,那么zkfc就会标记它处于一个不健康的状态2.会话管理:如果NN是健康的,zkfc就会在zookeeper中保持一个打开的会话,如果NameNode同时还是Active状态的,那么zkfc还会在Zookeeper中占有一个类型为短暂类型的znode,当这个NN挂掉时,这个znode将会被删除,然后备用的NN将会得到这把锁,升级为主NN,同时标记状态为Active3.master选举:通过在zookeeper中维持一个短暂类型的znode,来实现抢占式的锁机制,从而判断那个NameNode为Active状态4.当宕机的NN新启动时,它会再次注册zookeper,发现已经有znode锁了,便会自动变为Standby状态,如此往复循环,保证高可靠
    
    • 1
    • 2
    • 3

    在这里插入图片描述

    高可用服务

    NN: NameNode
    DN: DataNode
    
    RM: ResourceManager
    NM: NodeManager
    
    JN: JournalNode
    ZK: ZooKeeper
    ZKFC: DFSZKFailoverController
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9

    在这里插入图片描述

    启动hadoop高可用环境

    # 1.先恢复快照到高可用环境
    
    # 2.三台服务器启动zookeeper服务
    [root@node1 ~]# zkServer.sh start
    [root@node2 ~]# zkServer.sh start
    [root@node3 ~]# zkServer.sh start
    
    # 3.在node1中启动hadoop集群
    [root@node1 ~]# start-all.sh
    
    # 4.检查服务
    [root@node1 ~]# jps
    [root@node2 ~]# jps
    [root@node3 ~]# jps
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7
    • 8
    • 9
    • 10
    • 11
    • 12
    • 13
    • 14

    在这里插入图片描述

    NameNode高可用:

    web链接:

    node1:50070

    node2:50070

    可以使用kill -9 NN进程号把其中主服务杀掉,观察效果,然后使用 hdfs --daemon start namenode 重启,再次观察效果

    在这里插入图片描述
    在这里插入图片描述

    active: namenode主服务
    standby: namenode备份服务
    
    • 1
    • 2

    ResourceManager高可用

    web链接:

    node1:8088

    node2:8088

    可以使用kill -9 RM进程号把其中主服务杀掉,观察效果,然后使用 yarn --daemon start resourcemanager 重启,再次观察效果

    注意: 两个服务同时启动,按照上述链接去访问会自动跳到同一个主节点页面

    在这里插入图片描述

  • 相关阅读:
    华为云云耀云服务器L实例评测|部署spring项目端口开放问题的解决 & 服务器项目环境搭建MySQL,Redis,Minio...指南
    探寻欧洲市场的机遇:深度剖析欧洲跨境电商
    ACCESS_MASK不明确的符号
    以太网诊断协议DoIP(Ethernet Diagnostic Protocol DoIP)
    主流开发语言和开发环境?
    【斗罗二】再度魔改,弓老被删,冰帝武魂提前曝光,官方经费已不足
    ArcGIS Pro SDK for .Net Add-in插件开发教程
    驱动开发--自动创建节点udev机制的实现过程分析
    ARM day9
    java: 无效的源发行版: 11解决方法
  • 原文地址:https://blog.csdn.net/weixin_46010015/article/details/134494780