zookeeper_zookeeper缺点 - CSDN
zookeeper 订阅
ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。ZooKeeper包含一个简单的原语集,提供Java和C的接口。ZooKeeper代码版本中,提供了分布式独享锁、选举、队列的接口,代码在$zookeeper_home\src\recipes。其中分布锁和队列有Java和C两个版本,选举只有Java版本。(概述图片来源: [1]  ) 展开全文
ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。ZooKeeper包含一个简单的原语集,提供Java和C的接口。ZooKeeper代码版本中,提供了分布式独享锁、选举、队列的接口,代码在$zookeeper_home\src\recipes。其中分布锁和队列有Java和C两个版本,选举只有Java版本。(概述图片来源: [1]  )
信息
所    属
Hadoop的正式子项目
外文名
ZooKeeper
领    域
大数据技术,分布式系统
类    别
分布式系统的可靠协调系统
特    点
高效,可靠
zookeeper原理
ZooKeeper是以Fast Paxos算法为基础的,Paxos 算法存在活锁的问题,即当有多个proposer交错提交时,有可能互相排斥导致没有一个proposer能提交成功,而Fast Paxos做了一些优化,通过选举产生一个leader (领导者),只有leader才能提交proposer,具体算法可见Fast Paxos。因此,要想弄懂ZooKeeper首先得对Fast Paxos有所了解。ZooKeeper的基本运转流程:1、选举Leader。2、同步数据。3、选举Leader过程中算法有很多,但要达到的选举标准是一致的。4、Leader要具有最高的执行ID,类似root权限。5、集群中大多数的机器得到响应并接受选出的Leader。
收起全文
  • ZooKeeper入门视频课程

    2020-01-16 10:26:10
    本课程以通俗易懂的方式讲解ZooKeeper技术,课程内容包括: 1. ZooKeeper简介、应用场景 2. ZooKeeper文件系统和通知机制 3. ZooKeeper安装 4. 客户端操作、常用命令 5. ZooKeeper集群(配置集群、集群特性、...
  • zookeeper

    2018-11-21 01:45:46
    zookeeper有配置维护、域名服务、分布式同步、组服务等这些功能,它可以通过投票选举机制选举出leader,并且在hbase中,zookeeper尤为重要,zookeeper存储了hbase的元数据,所以想要搭建hbase集群之前,必

    一、zookeeper

    ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。zookeeper有配置维护、域名服务、分布式同步、组服务等这些功能,它可以通过投票选举机制选举出leader,并且在hbase中,zookeeper尤为重要,zookeeper存储了hbase的元数据,所以想要搭建hbase集群之前,必须要搭建zookeeper。

    操作步骤

    1. zookeeper3.4.10下载

    zookeeper下载地址,并上传到主服务器的/opt目录下
    虽然zookeeper在我们hadoop集群的三个节点都需要安装,但我们可以先在主服务器上做好配置,然后分发到从服务器

    2. zookeeper解压并修改目录名

     # cd /opt
     # tar -xzvf zookeeper-3.4.10.tar.gz
     # mv zookeeper-3.4.10 zookeeper3.4.10
    

    3. 创建data和dataLog目录

     # mkdir /opt/zookeeper3.4.10/data                      # 创建data目录
     # mkdir /opt/zookeeper3.4.10/dataLog                # 创建dataLog目录
    

    4. 创建myid文件

     # cd /opt/zookeeper3.4.10/data
     # vim myid                  # 输入数字1,然后保存,第二个节点输入2,第三个节点输入3
    
     # chmod 777 -R /opt/zookeeper3.4.10    # 对zookeeper的目录进行授权
    

    5. 修改配置文件zoo.cfg

     # cd /opt/zookeeper3.4.10/conf
     # cp zoo_sample.cfg zoo.cfg
     # vim zoo.cfg             #在文件末尾添加如下内容
    
    dataDir=/opt/zookeeper3.4.10/data  
    dataLogDir=/opt/zookeeper3.4.10/dataLog  
    server.1=hadoop0:2888:3888  
    server.2=hadoop1:2888:3888  
    server.3=hadoop2:2888:3888  
    
     # 注hadoop0,hadoop1,hadoop2为三个节点的主机名!
    

    6. 把在主节点上修改的zookeeper分发到hadoop1和hadoop2

     # cd /opt/
     # scp -r zookeeper3.4.10  root@hadoop1:/opt/
     # scp -r zookeeper3.4.10  root@hadoop2:/opt/
    

    分发后别忘了修改data目录下的myid文件中的内容,也给从节点的zookeeper目录赋权

    7. 启动和测试集群

    分别在三台服务器上运行如下命令
     # zkServer.sh start
    

    8. 验证效果

    分别在三台服务器上运行如下命令
     # zkServer.sh status
    

    这里写图片描述

    这里写图片描述

    这里写图片描述

    查看zookeeper集群中的zookeeper节点的状态,会发现其中一个是leader,其余是follower。这就是zookeeper的投票选举机制,所以一般zookeeper为单数个节点的集群,这样投票容易一些;当然如果双数节点也可以,只是投票难度大了一些,比如6个节点的zookeeper,那么必须一个节点票数为4票及以上,才行,而不像单数个节点!

    二、注意

    安装了zookeeper集群之后,应用命令zkServer.sh start后,启动了zookeeper服务,用jps进程发现存在QuorumPeerMain进程,但是查看zookeeper状态的时候,发现报Error contacting service. It is probably not running.错误,提示服务并没有启动,那这是什么原因呢?原因可能有多种造成的,下面我们来分析一下。

    操作步骤

    报错提示如下:

    这里写图片描述

    1. 查看zoo.cfg文件

    查看最后添加的内容,server后面的数字为data目录下myid中的数字,hadoop0,hadoop1,hadoop2为自己的主机名!

     # vim /opt/zookeeper3.4.10/conf/zoo.cfg
     
     dataDir=/opt/zookeeper3.4.10/data  
     dataLogDir=/opt/zookeeper3.4.10/dataLog  
     server.1=hadoop0:2888:3888  
     server.2=hadoop1:2888:3888  
     server.3=hadoop2:2888:3888
    

    2. 查看data目录中的myid文件

    如果myid文件中的数字不和zoo.cfg中的数字对应,也会造成错误!

    # vim /opt/zookeeper3.4.10/data/myid
    

    我当时就是把数字搞错了,第一个myid中的数字为1,第二个myid中的数字为2,第三个myid中的数字还是写的2,最后导致第三个服务器的zookeeper老是报错,排查了一会!

    3. 查看防火墙是否关闭

     # systemctl stop firewalld.service
     # systemctl disable firewalld.service
    
    展开全文
  • 相信大家对 ZooKeeper 应该不算陌生,但是你真的了解 ZooKeeper 是什么吗?如果别人/面试官让你讲讲 ZooKeeper 是什么,你能回答到哪个地步呢? 我本人曾经使用过 ZooKeeper 作为 Dubbo 的注册中心,另外在搭建 ...

    相信大家对 ZooKeeper 应该不算陌生,但是你真的了解 ZooKeeper 是什么吗?如果别人/面试官让你讲讲 ZooKeeper 是什么,你能回答到哪个地步呢?

    我本人曾经使用过 ZooKeeper 作为 Dubbo 的注册中心,另外在搭建 Solr 集群的时候,我使用到了 ZooKeeper 作为 Solr 集群的管理工具。

    前几天,总结项目经验的时候,我突然问自己 ZooKeeper 到底是个什么东西?

    想了半天,脑海中只是简单的能浮现出几句话:

    • Zookeeper 可以被用作注册中心

    • Zookeeper 是 Hadoop 生态系统的一员。

    • 构建 Zookeeper 集群的时候,使用的服务器最好是奇数台。

    可见,我对于 Zookeeper 的理解仅仅是停留在了表面。所以,通过本文,希望带大家稍微详细的了解一下 ZooKeeper 。

    如果没有学过 ZooKeeper,那么本文将会是你进入 ZooKeeper 大门的垫脚砖;如果你已经接触过 ZooKeeper ,那么本文将带你回顾一下 ZooKeeper 的一些基础概念。

    最后,本文只涉及 ZooKeeper 的一些概念,并不涉及 ZooKeeper 的使用以及 ZooKeeper 集群的搭建。

    网上有介绍 ZooKeeper 的使用以及搭建 ZooKeeper 集群的文章,大家有需要可以自行查阅。

    什么是 ZooKeeper

    ZooKeeper 的由来

    下面这段内容摘自《从 Paxos 到 ZooKeeper 》第四章第一节的某段内容,推荐大家阅读一下:

    Zookeeper 最早起源于雅虎研究院的一个研究小组。在当时,研究人员发现,在雅虎内部很多大型系统基本都需要依赖一个类似的系统来进行分布式协调,但是这些系统往往都存在分布式单点问题。

    所以,雅虎的开发人员就试图开发一个通用的无单点问题的分布式协调框架,以便让开发人员将精力集中在处理业务逻辑上。

    关于“ZooKeeper”这个项目的名字,其实也有一段趣闻。在立项初期,考虑到之前内部很多项目都是使用动物的名字来命名的(例如著名的Pig项目),雅虎的工程师希望给这个项目也取一个动物的名字。

    时任研究院的首席科学家 Raghu Ramakrishnan 开玩笑地说:“在这样下去,我们这儿就变成动物园了!”

    此话一出,大家纷纷表示就叫动物园管理员吧,因为各个以动物命名的分布式组件放在一起,雅虎的整个分布式系统看上去就像一个大型的动物园了。

    而 Zookeeper 正好要用来进行分布式环境的协调,于是,Zookeeper 的名字也就由此诞生了。

    ZooKeeper 概览

    ZooKeeper 是一个开源的分布式协调服务,ZooKeeper 框架最初是在“Yahoo!"上构建的,用于以简单而稳健的方式访问他们的应用程序。

    后来,Apache ZooKeeper 成为 Hadoop,HBase 和其他分布式框架使用的有组织服务的标准。

    例如,Apache HBase 使用 ZooKeeper 跟踪分布式数据的状态。

    ZooKeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集,并以一系列简单易用的接口提供给用户使用。

    原语: 操作系统或计算机网络用语范畴。它是由若干条指令组成的,用于完成一定功能的一个过程。具有不可分割性,即原语的执行必须是连续的,在执行过程中不允许被中断。

    ZooKeeper 是一个典型的分布式数据一致性解决方案,分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅负载均衡命名服务分布式协调/通知集群管理Master 选举分布式锁分布式队列等功能。

    ZooKeeper 一个最常用的使用场景就是用于担任服务生产者和服务消费者的注册中心。

    服务生产者将自己提供的服务注册到 ZooKeeper 中心,服务的消费者在进行服务调用的时候先到 ZooKeeper 中查找服务,获取到服务生产者的详细信息之后,再去调用服务生产者的内容与数据。

    如下图所示,在 Dubbo 架构中 ZooKeeper 就担任了注册中心这一角色。

    Dubbo 架构图

    结合个人使用讲一下 ZooKeeper

    在我自己做过的项目中,主要使用到了 ZooKeeper 作为 Dubbo 的注册中心(Dubbo 官方推荐使用 ZooKeeper 注册中心)。

    另外在搭建 Solr 集群的时候,我使用  ZooKeeper 作为 Solr 集群的管理工具。

    这时,ZooKeeper 主要提供下面几个功能:

    • 集群管理:容错、负载均衡

    • 配置文件的集中管理。

    • 集群的入口。

    我个人觉得在使用 ZooKeeper 的时候,最好是使用集群版的 ZooKeeper 而不是单机版的。

    官网给出的架构图就描述的是一个集群版的 ZooKeeper 。通常 3 台服务器就可以构成一个  ZooKeeper 集群

    为什么最好使用奇数台服务器构成 ZooKeeper 集群?

    我们知道在 ZooKeeper 中 Leader 选举算法采用了 Zab 协议。Zab 核心思想是当多数 Server 写成功,则任务数据写成功:

    • 如果有 3 个 Server,则最多允许 1 个 Server 挂掉。

    • 如果有 4 个 Server,则同样最多允许 1 个 Server 挂掉。

    既然 3 个或者 4 个 Server,同样最多允许 1 个 Server 挂掉,那么它们的可靠性是一样的。

    所以选择奇数个 ZooKeeper Server 即可,这里选择 3 个 Server。

    关于 ZooKeeper  的一些重要概念

    重要概念总结

    关于 ZooKeeper  的一些重要概念:

    • ZooKeeper 本身就是一个分布式程序只要半数以上节点存活,ZooKeeper 就能正常服务)。

    • 为了保证高可用,最好是以集群形态来部署 ZooKeeper,这样只要集群中大部分机器是可用的(能够容忍一定的机器故障),那么 ZooKeeper 本身仍然是可用的。

    • ZooKeeper 将数据保存在内存中这也就保证了 高吞吐量和低延迟(但是内存限制了能够存储的容量不太大,此限制也是保持 Znode 中存储的数据量较小的进一步原因)。

    • ZooKeeper 是高性能的。在“读”多于“写”的应用程序中尤其地高性能,因为“写”会导致所有的服务器间同步状态。(“读”多于“写”是协调服务的典型场景。)

    • ZooKeeper 有临时节点的概念。当创建临时节点的客户端会话一直保持活动,瞬时节点就一直存在。

      而当会话终结时,瞬时节点被删除。持久节点是指一旦这个 ZNode 被创建了,除非主动进行 ZNode 的移除操作,否则这个 ZNode 将一直保存在 Zookeeper 上。

    • ZooKeeper 底层其实只提供了两个功能:①管理(存储、读取)用户程序提交的数据;②为用户程序提交数据节点监听服务。

    下面关于会话(Session)、 Znode、版本、Watcher、ACL 概念的总结都在《从 Paxos 到 ZooKeeper 》第四章第一节以及第七章第八节有提到,感兴趣的可以看看!

    会话(Session)

    Session 指的是 ZooKeeper  服务器与客户端会话。在 ZooKeeper 中,一个客户端连接是指客户端和服务器之间的一个 TCP 长连接。

    客户端启动的时候,首先会与服务器建立一个 TCP 连接,从第一次连接建立开始,客户端会话的生命周期也开始了。

    通过这个连接,客户端能够通过心跳检测与服务器保持有效的会话,也能够向 Zookeeper 服务器发送请求并接受响应,同时还能够通过该连接接收来自服务器的 Watch 事件通知。

    Session 的 sessionTimeout 值用来设置一个客户端会话的超时时间。

    当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时,只要在 sessionTimeout 规定的时间内能够重新连接上集群中任意一台服务器,那么之前创建的会话仍然有效。

    在为客户端创建会话之前,服务端首先会为每个客户端都分配一个 sessionID。

    由于 sessionID 是 Zookeeper 会话的一个重要标识,许多与会话相关的运行机制都是基于这个 sessionID 的。

    因此,无论是哪台服务器为客户端分配的 sessionID,都务必保证全局唯一。

    Znode

    在谈到分布式的时候,我们通常说的“节点"是指组成集群的每一台机器。

    然而,在 ZooKeeper 中,“节点"分为两类:

    • 第一类同样是指构成集群的机器,我们称之为机器节点

    • 第二类则是指数据模型中的数据单元,我们称之为数据节点一ZNode。

    ZooKeeper 将所有数据存储在内存中,数据模型是一棵树(Znode Tree),由斜杠(/)的进行分割的路径,就是一个 Znode,例如/foo/path1。每个上都会保存自己的数据内容,同时还会保存一系列属性信息。

    在 Zookeeper 中,Node 可以分为持久节点和临时节点两类。所谓持久节点是指一旦这个 ZNode 被创建了,除非主动进行 ZNode 的移除操作,否则这个 ZNode 将一直保存在 ZooKeeper 上。

    而临时节点就不一样了,它的生命周期和客户端会话绑定,一旦客户端会话失效,那么这个客户端创建的所有临时节点都会被移除。

    另外,ZooKeeper 还允许用户为每个节点添加一个特殊的属性:SEQUENTIAL。

    一旦节点被标记上这个属性,那么在这个节点被创建的时候,ZooKeeper 会自动在其节点名后面追加上一个整型数字,这个整型数字是一个由父节点维护的自增数字。

    版本

    在前面我们已经提到,Zookeeper 的每个 ZNode 上都会存储数据,对应于每个 ZNode,Zookeeper 都会为其维护一个叫作 Stat 的数据结构。

    Stat 中记录了这个 ZNode 的三个数据版本,分别是:

    • version(当前 ZNode 的版本)

    • cversion(当前 ZNode 子节点的版本)

    • aversion(当前 ZNode 的 ACL 版本)

    Watcher

    Watcher(事件监听器),是 ZooKeeper 中的一个很重要的特性。

    ZooKeeper 允许用户在指定节点上注册一些 Watcher,并且在一些特定事件触发的时候,ZooKeeper 服务端会将事件通知到感兴趣的客户端上去,该机制是 ZooKeeper 实现分布式协调服务的重要特性。

    ACL

    ZooKeeper 采用 ACL(AccessControlLists)策略来进行权限控制,类似于  UNIX 文件系统的权限控制。

    ZooKeeper 定义了 5 种权限,如下图:

     

    其中尤其需要注意的是,CREATE 和 DELETE 这两种权限都是针对子节点的权限控制。

    ZooKeeper 特点

    ZooKeeper 有哪些特点呢?具体如下:

    • 顺序一致性:从同一客户端发起的事务请求,最终将会严格地按照顺序被应用到 ZooKeeper 中去。

    • 原子性:所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的,也就是说,要么整个集群中所有的机器都成功应用了某一个事务,要么都没有应用。

    • 单一系统映像:无论客户端连到哪一个 ZooKeeper 服务器上,其看到的服务端数据模型都是一致的。

    • 可靠性:一旦一次更改请求被应用,更改的结果就会被持久化,直到被下一次更改覆盖。

    ZooKeeper 设计目标

    简单的数据模型

    ZooKeeper 允许分布式进程通过共享的层次结构命名空间进行相互协调,这与标准文件系统类似。

    名称空间由 ZooKeeper 中的数据寄存器组成,称为 Znode,这些类似于文件和目录。

    与为存储设计的典型文件系统不同,ZooKeeper 数据保存在内存中,这意味着 ZooKeeper 可以实现高吞吐量和低延迟。

     

    可构建集群

    为了保证高可用,最好是以集群形态来部署 ZooKeeper,这样只要集群中大部分机器是可用的(能够容忍一定的机器故障),那么 ZooKeeper 本身仍然是可用的。 

    客户端在使用 ZooKeeper 时,需要知道集群机器列表,通过与集群中的某一台机器建立 TCP 连接来使用服务。

    客户端使用这个 TCP 链接来发送请求、获取结果、获取监听事件以及发送心跳包。如果这个连接异常断开了,客户端可以连接到另外的机器上。

    ZooKeeper 官方提供的架构图:

    上图中每一个 Server 代表一个安装 ZooKeeper 服务的服务器。组成 ZooKeeper 服务的服务器都会在内存中维护当前的服务器状态,并且每台服务器之间都互相保持着通信。

    集群间通过 Zab 协议(Zookeeper Atomic Broadcast)来保持数据的一致性。

    顺序访问

    对于来自客户端的每个更新请求,ZooKeeper 都会分配一个全局唯一的递增编号。

    这个编号反应了所有事务操作的先后顺序,应用程序可以使用 ZooKeeper 这个特性来实现更高层次的同步原语。这个编号也叫做时间戳—zxid(ZooKeeper Transaction Id)。

    高性能

    ZooKeeper 是高性能的。在“读”多于“写”的应用程序中尤其地高性能,因为“写”会导致所有的服务器间同步状态。(“读”多于“写”是协调服务的典型场景。)

    ZooKeeper 集群角色介绍

    最典型集群模式:Master/Slave 模式(主备模式)。在这种模式中,通常 Master 服务器作为主服务器提供写服务,其他的 Slave 服务器从服务器通过异步复制的方式获取 Master 服务器最新的数据提供读服务。

    但是,在 ZooKeeper 中没有选择传统的 Master/Slave 概念,而是引入了Leader、Follower 和 Observer 三种角色。

    如下图所示:

     

    ZooKeeper 集群中的所有机器通过一个 Leader 选举过程来选定一台称为 “Leader” 的机器。

    Leader 既可以为客户端提供写服务又能提供读服务。除了 Leader 外,Follower 和  Observer 都只能提供读服务。

    Follower 和 Observer 唯一的区别在于 Observer 机器不参与 Leader 的选举过程,也不参与写操作的“过半写成功”策略,因此 Observer 机器可以在不影响写性能的情况下提升集群的读性能。

     

    ZooKeeper & ZAB 协议 & Paxos 算法

    ZAB 协议 & Paxos 算法

    Paxos 算法可以说是  ZooKeeper 的灵魂了。但是,ZooKeeper 并没有完全采用 Paxos 算法 ,而是使用 ZAB 协议作为其保证数据一致性的核心算法。

    另外,在 ZooKeeper 的官方文档中也指出,ZAB 协议并不像 Paxos 算法那样,是一种通用的分布式一致性算法,它是一种特别为 ZooKeeper 设计的崩溃可恢复的原子消息广播算法。

    ZAB 协议介绍

    ZAB(ZooKeeper Atomic Broadcast 原子广播)协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。

    在 ZooKeeper 中,主要依赖 ZAB 协议来实现分布式数据一致性,基于该协议,ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

    ZAB 协议两种基本的模式

    ZAB 协议包括两种基本的模式,分别是崩溃恢复和消息广播。

    当整个服务框架在启动过程中,或是当 Leader 服务器出现网络中断、崩溃退出与重启等异常情况时,ZAB 协议就会进入恢复模式并选举产生新的 Leader 服务器。

    当选举产生了新的 Leader 服务器,同时集群中已经有过半的机器与该 Leader 服务器完成了状态同步之后,ZAB 协议就会退出恢复模式。

    其中,所谓的状态同步是指数据同步,用来保证集群中存在过半的机器能够和 Leader 服务器的数据状态保持一致。

    当集群中已经有过半的 Follower 服务器完成了和 Leader 服务器的状态同步,那么整个服务框架就可以进人消息广播模式了。 

    当一台同样遵守 ZAB 协议的服务器启动后加入到集群中时,如果此时集群中已经存在一个 Leader 服务器在负责进行消息广播。

    那么新加入的服务器就会自觉地进人数据恢复模式:找到 Leader 所在的服务器,并与其进行数据同步,然后一起参与到消息广播流程中去。

    正如上文介绍中所说的,ZooKeeper 设计成只允许唯一的一个 Leader 服务器来进行事务请求的处理。

    Leader 服务器在接收到客户端的事务请求后,会生成对应的事务提案并发起一轮广播协议。

    而如果集群中的其他机器接收到客户端的事务请求,那么这些非 Leader 服务器会首先将这个事务请求转发给 Leader 服务器。

    关于 ZAB 协议 & Paxos 算法需要讲和理解的东西太多了,推荐阅读下面两篇文章:

    • 图解 Paxos 一致性协议:

      http://blog.xiaohansong.com/2016/09/30/Paxos/

    • Zookeeper ZAB 协议分析:

      http://blog.xiaohansong.com/2016/08/25/zab/

    关于如何使用 ZooKeeper 实现分布式锁,可以查看下面这篇文章:

    • Zookeeper ZAB 协议分析:

      https://blog.csdn.net/qiangcuo6087/article/details/79067136

    总结

    通过阅读本文,想必大家已从以下这七点了解了 ZooKeeper:

    • ZooKeeper 的由来

    • ZooKeeper 到底是什么

    • ZooKeeper 的一些重要概念(会话(Session)、Znode、版本、Watcher、ACL)

    • ZooKeeper 的特点

    • ZooKeeper 的设计目标

    • ZooKeeper 集群角色介绍(Leader、Follower 和 Observer 三种角色)

    • ZooKeeper & ZAB 协议 & Paxos 算法

    参考文章:

    • 《从Paxos到Zookeeper 》

    • https://cwiki.apache.org/confluence/display/ZOOKEEPER/ProjectDescription

    • https://cwiki.apache.org/confluence/display/ZOOKEEPER/Index

    • https://www.cnblogs.com/raphael5200/p/5285583.html

    • https://zhuanlan.zhihu.com/p/30024403

    作者:SnailClimb

    编辑:陶家龙、孙淑娟

    出处:本文经授权转载自Java 面试通关手册(ID:Java_Guide)微信公众号

    展开全文
  • 鉴于CSDN对**版权保护的不作为**以及落后的运营手段,本博客将于近期关闭,并清空全部文章。 原有文章将会经过再次的校对、整理,转移至本人在**简书**的[博客空间](https://www.jianshu.com/u/3ec23ef9a408)... ...


    鉴于CSDN对**版权保护的不作为**以及落后的运营手段,本博客将于近期关闭,并清空全部文章。

    原有文章将会经过再次的校对、整理,转移至本人在**简书**的[博客空间](https://www.jianshu.com/u/3ec23ef9a408)。

    展开全文
  • zookeeper简介(一)

    2018-09-27 18:50:38
    原文地址,转载请注明出处:&...ZooKeeper(后面称为zk)是一种用于分布式应用程序的分布式开源协调服务。主要是用来解决分布式应用中经常遇到的一些问题,假如你公司的项目还是处于单机状态,那可能用...

    原文地址,转载请注明出处: https://blog.csdn.net/qq_34021712/article/details/82870721     ©王赛超 

    介绍

    ZooKeeper(后面称为zk)是一种用于分布式应用程序的分布式开源协调服务。主要是用来解决分布式应用中经常遇到的一些问题,假如你公司的项目还是处于单机状态,那可能用不到zk,一旦涉及到分布式应用,很多问题都可以利用zk解决。
    官网地址:http://zookeeper.apache.org/doc/current/zookeeperOver.html

    1.设计目标

    • 简单
    • 高可靠
    • 有序
    • 高性能

    下面一一介绍:

    简单的数据模型

    在这里插入图片描述
    zk允许各分布式应用通过一个共享的命名空间相互联系,该命名空间类似于一个标准的文件系统:由若干注册了的数据节点构成(用zk的术语叫znode),这些节点类似于文件和目录。与专为存储而设计的典型文件系统不同,zk数据保存在内存中,这意味着zk可以实现高吞吐量和低延迟数量。

    高可靠

    在这里插入图片描述
    就像zk需要协调的分布式系统一样,它本身就是具有冗余结构,它构建在一系列主机之上,构成zk服务的各服务器之间必须相互知道,它们维护着一个状态信息的内存映像,以及在持久化存储中维护着事务日志和快照。只要大部分服务器正常工作,zk服务就能正常工作。客户端连接到一台zk服务器。客户端维护这个TCP连接,通过这个连接,客户端可以发送请求、得到应答,得到监视事件以及发送心跳。如果这个连接断了,客户端可以连接到另一个zk服务器。
       1.客户端随机连接集群中任何一台server
       2.集群内所有server基于Zab(ZooKeeper Atomic Broadcast)协议进 行通信
       3.集群内部根据算法自动选举出一个leader,负责向follower(其他 server)广播所有变化消息
       4.集群中每个follower都和leader通信
             • Follower接收来自leader的所有变化消息,保存在自己内存
             • Follower转发来自客户端的写请求给leader
             • 客户端的读请求会在follower端直接服务,无需转发给leader

    zk集群角色

    Leader
    ①Leader服务器是zk集群工作机制的核心.
    ②事务请求的唯一调度者和处理者,保证集群事务请求处理的顺序性.
    Follower
    ①Follower服务器是zk集群状态的跟随者.
    ②处理非事务请求,转发事务请求给Leader服务器
    ③参与事务请求的proposal投票
    ④参与Leader选举投票
    Observer
    Observer是一种新型的zk节点,Observer服务器只提供非事务服务.通常用于不影响集群事务处理能力的前提下提升集群的非事务的处理能力,Observer有另外一个优势,因为它不参与投票,所以他们不属于zk集群的关键部位,即使他们Failed,或者从集群中断开,也不会影响集群的可用性。

    有序性

    zk给每次更新附加一个数字标签,表明zk中的事务顺序,后续操作可以利用这个顺序来完成更高层次的抽象功能,例如同步原语操作。

    高性能

    zk特别适合于以读为主要负荷的场合。zk可以运行在数千台机器上,如果大部分操作为读,例如读写比例为10:1,zk的效率会很高。

    下面了解一下数据模型的一些操作:

    数据模型 与其操作

    和文章刚开始讲的简单的数据模型一样,zk提供的名称空间非常类似于标准文件系统。名称是由斜杠(/)分隔的路径元素序列。zk名称空间中的每个节点都由路径标识。

    节点介绍

    在zk中每个命名空间(Namespace)被称为znode,每个znode包含一个路径和与之相关的元数据,以及继承自该节点的孩子列表(临时节点下面不能创建子节点),zk旨在存储协调数据:状态信息,配置,位置信息等,因此存储在每个节点的数据通常很小,在字节到千字节范围内。

    一个znode维护了一个属性结构,该结构包括:版本号、ACL变更、时间戳。每次znode数据发生变化,版本号都会递增,这样客户端的读请求可以基于版本号来检索状态相关数据。

    每个znode都有一个ACL,用来限制是否可以访问该znode。

    在一个命名空间中,对znode上存储的数据执行读和写请求操作都是原子的。

    zk中有几种节点类型

    注意:节点类型在节点创建的时候就被确定且不可改变

    • 临时节点(EPHEMERAL):临时创建的,会话结束节点自动被删除,也可以手动删除,临时节点不能拥有子节点.
    • 持久节点(PERSISTENT):创建后永久存在,除非主动删除。

    以上两种节点为Non-sequence节点,只有一个可创建成功,其它匀失败。并且创建出的节点名称与创建时指定的节点名完全一样.

    • 临时顺序节点(EPHEMERAL_SEQUENTIAL):具有临时节点特征,但是它会有序列号。
    • 持久顺序节点(PERSISTENT_SEQUENTIAL):具有持久节点特征,但是它会有序列号。

    以上两种节点为sequence节点,创建出的节点名在指定的名称之后带有10位10进制数的序号。多个客户端创建同一名称的节点时,都能创建成功,只是序号不同

    • 容器节点(CONTAINER):如果节点中最后一个子Znode被删除,将会触发删除该Znode;
    • 持久定时节点(PERSISTENT_WITH_TTL):客户端断开连接后不会自动删除Znode,如果该Znode没有子Znode且在给定TTL时间内无修改,该Znode将会被删除;TTL单位是毫秒,必须大于0且小于或等于 EphemeralType.MAX_TTL
    • 持久顺序定时节点(PERSISTENT_SEQUENTIAL_WITH_TTL):同PERSISTENT_WITH_TTL,且Znode命名末尾自动添加递增编号;

    以上三种节点是在3.5.3-beta版中才有的

    节点信息

    每一个Znode都有对应的stat结构,和文件系统类似。stat状态主要包含下面的信息:

    • cZxid. 节点被创建时候的事务ID
    • mZxid 节点最后一次被修改时候的事务ID
    • pZxid 该节点的子节点最后一次被修改时的事务ID。子节点删除或添加才会影响pZxid
    • ctime 节点被创建的时间
    • mtime 节点被修改的世界
    • dataVersion 这个节点数据改变的次数
    • cversion 子节点被改变的次数
    • aclVersion 节点的ACL(访问控制列表被改变的次数)
    • ephemeralOwner 创建该临时节点的 session ID。如果是持久节点,设置为0
    • dataLength 数据内容长度
    • numChildren 当前节点子节点的个数

    可以使用ls2和stat命令查看ZooKeeper节点下的信息。

    节点的访问控制(ACL)

    zk提供了ACL来控制znode节点的访问,只有符合了ACL控制,才可以操作该节点,否则将无法操作。
    Zookeeper支持可配置的认证机制。它利用一个三元组来定义客户端的访问权限:
    (scheme:expression, perms) 。其中:

    1. Schema 代表权限控制模式,分别为:
      ● World 任何人
      ● Auth 不需要ID
      ● Digest 用户名和密码方式的认证
      ● IP Address IP地址方式的认证
    2. perms(权限),ZooKeeper支持如下权限
      ● CREATE: 创建子节点
      ● READ: 获取子节点与自身节点的数据信息
      ● WRITE:在Znode节点上写数据
      ● DELETE:删除子节点
      ● ADMIN:设置ACL权限

    注意:
    Znode的Acl只是针对某个节点,不会作用到它的子节点上
    任何连接到ZooKeeper的客户端都可以使用exist操作,exist是不需要权限的。

    zk可以保证如下特性:

    • 顺序一致性
      客户端的更新顺序与它们被发送的顺序一致。

    • 原子性
      更新操作要么成功,要么失败,没有第三种结果。

    • 单系统映像
      无论客户端连接到哪一个服务器,他都将看到相同的zk视图。

    • 可靠性
      一旦一个更新操作被应用,那么在客户端再次更新之前,其值不会再改变。

    • 实时性
      zk保证客户端将在一个时间间隔范围内获得服务器的更新信息,或者服务器失效的信息。 但由于网络延时等原因,zk不能保证两个客户端能同时得到刚更新的数据,如果需要最新数据,应该在读数据之前调用sync()接口。

    Zookeeper Watch机制

    zk支持监听, 客户端能够设置监听znode节点. 当znode节点变更时可能触发或者移除监听.当监听事件被触发了,客户端将会收到数据通知包,告诉客户端节点数据被修改了. 同时如果当前客户端和zk节点的连接被断开了.客户端将收到一个本地通知.

    有如下的Watcher事件类型可能出现:
    • NodeChildrenChanged: zNode的子节点创建或删除的时候
    • NodeCreated: 新的Znode节点被创建的时候
    • NodeDataChanged: Znode节点的数据改变了的时候
    • NodeDeleted: Znode节点被删除的时候。
    Watcher操作特点
    • 主动推送 Watch被触发时,由 zk 服务器主动将更新推送给客户端,而不需要客户端轮询。
    • 一次性 数据变化时,Watch 只会被触发一次。如果客户端想得到后续更新的通知,必须要在 Watch 被触发后重新注册一个 Watch。
    • 可见性 如果一个客户端在读请求中附带 Watch,Watch 被触发的同时再次读取数据,客户端在得到 Watch 消息之前肯定不可能看到更新后的数据。换句话说,更新通知先于更新结果。
    • 顺序性 如果多个更新触发了多个 Watch ,那 Watch 被触发的顺序与更新顺序一致。避免安装大量watches侦听在同一个节点
    • 无法保证跟踪到每一个变化

    ZooKeeper Session

    1. 客户端和server间采用长连接
    2. 连接建立后,server产生session ID(64位)返还 给客户端
    3. 客户端定期发送ping包来检查和保持和server的 连接
    4. 一旦session结束或超时,所有ephemeral节点会 被删除
    5. 客户端可根据情况设置合适的session超时时间
    6. 客户端能够异步接收来自服务端的Watcher事件通知

    ZooKeeper典型8大应用场景及对应的特性:

    配置管理服务

    例如当当的configtoolkit配置中心,就是将配置信息放到了zk上,假如你有20个节点,需要修改配置文件的时候,你总不能一个节点一个节点去更改吧 那假如有100个节点呢?在分布式系统中,有很多实例中的大多数配置项是相同的(比如数据库连接等),需要改变配置项,如果有zk的话,不需要在每个实例去修改。所有实例在启动时,都回去zk拉取节点信息,当节点信息修改的时候会通知到每一个实例,某些配置项也可以达到热配置的效果。

    集群管理(Master选举)

    在分布式的集群中,经常会由于各种原因,比如硬件故障,软件故障,网络问题,有些节点会进进出出。有新的节点加入进来,也有老的节点退出集群。这个时候,集群中其他机器需要感知到这种变化,然后根据这种变化做出对应的决策。比如我们是一个分布式存储系统,有一个中央控制节点负责存储的分配,当有新的存储进来的时候我们要根据现在集群目前的状态来分配存储节点。这个时候我们就需要动态感知到集群目前的状态。还有,比如一个分布式的SOA架构中,服务是一个集群提供的,当消费者访问某个服务时,就需要采用某种机制发现现在有哪些节点可以提供该服务(这也称之为服务发现,比如Alibaba开源的SOA框架Dubbo就采用了zk作为服务发现的底层机制)。还有开源的Kafka队列就采用了zk作为Cosnumer的上下线管理。
    还有一个场景:集群选master,一旦master挂掉能够马上能从slave中选出一个master,这个实现和上面实现一样。

    命名服务

    命名服务就是指通过指定的名字来获取资源或者服务的地址。zk会在自己的文件系统上(树结构的文件系统)创建一个以路径为名称的节点,它可以指向提供的服务的地址,远程对象等。分布式服务框架Dubbo中使用ZooKeeper来作为其命名服务,维护全局的服务地址列表。

    分布式计数器

    在分布式环境下,获取唯一id,功能和redis自增返回值一样,指定一个Zookeeper数据节点作为计数器,多个应用实例在分布式锁的控制下,通过更新该数据节点的内容来实现计数功能。

    分布式协调通知

    说分布式协调通知就有点广了,上面所说的配置服务和集群管理就是用到了分布式协调通知,分布式协调/通知服务是分布式系统中不可缺少的一个环节,是将不同的分布式组件有机结合起来的关键所在。
    利用zk中特有的Watcher注册与异步通知机制,能够很好的实现分布式环境下不同机器,甚至是不同系统之间的协调与通知,从而实现对数据变更的实时处理。
    利用zk的心跳机制和临时节点特性,可以让不同的机器都在zk的一个指定节点下创建临时子节点,不同的机器之间可以根据这个临时节点来判断对应的客户端机器是否存活。通过这种方式,检测系统和被检测系统之间并不需要直接相关联,而是通过zk上的某个节点进行关联,大大减少了系统耦合。

    发布订阅

    发布/订阅模式是一对多的关系,多个订阅者对象同时监听某一主题对象,这个主题对象在自身状态发生变化时会通知所有的订阅者对象。使它们能自动的更新自己的状态。发布/订阅可以使得发布方和订阅方独立封装、独立改变。当一个对象的改变需要同时改变其他对象,而且它不知道具体有多少对象需要改变时可以使用发布/订阅模式。发布/订阅模式在分布式系统中的典型应用有配置管理和服务发现、注册。

    配置管理是指如果集群中的机器拥有某些相同的配置并且这些配置信息需要动态的改变,我们可以使用发布/订阅模式把配置做统一集中管理,让这些机器格子各自订阅配置信息的改变,当配置发生改变时,这些机器就可以得到通知并更新为最新的配置。

    服务发现、注册是指对集群中的服务上下线做统一管理。每个工作服务器都可以作为数据的发布方向集群注册自己的基本信息,而让某些监控服务器作为订阅方,订阅工作服务器的基本信息,当工作服务器的基本信息发生改变如上下线、服务器角色或服务范围变更,监控服务器可以得到通知并响应这些变化。

    分布式锁

    每个客户端对某个方法加锁时,在zk上的与该方法对应的指定节点的目录下,生成一个唯一的瞬时有序节点。 判断是否获取锁的方式很简单,只需要判断自己创建的子节点是否为当前子节点列表中序号最小的子节点,如果是则认为获得锁,否则监听/lock的子节点变更消息,获得子节点变更通知后重复此步骤直至获得锁。

    队列管理

    zk队列不太适合要求高性能的场合,可以考虑在数据量不大的情况下使用。毕竟引进一个消息中间件会增加系统的复杂性和运维的压力。当然了,首先已有项目中要使用zk。
    使用zk实现先进先出队列就是在特定的目录下创建PERSISTENT_EQUENTIAL(永久、序列化)节点,创建成功时Watcher通知等待的队列,队列删除序列号最小的节点用以消费。此场景下zk的znode用于消息存储,znode存储的数据就是消息队列中的消息内容,SEQUENTIAL序列号就是消息的编号,按序取出即可。由于创建的节点是持久化的,所以不必担心队列消息的丢失问题。
    SEQUENTIAL:一旦节点被标记上SEQUENTIAL这个属性,那么在这个节点被创建的时候,ZooKeeper 就会自动在其节点后面追加上一个整型数字,这个整型数字是一个由父节点维护的自增数字。

    展开全文
  • 转自:点击打开链接1、Zookeeper的角色 » 领导者(leader),负责进行投票的发起和决议,更新系统状态 » 学习者(learner),包括跟随者(follower)和观察者(observer),follower用于接受客户端请求并想...

    转自:点击打开链接

    1、Zookeeper的角色

      » 领导者(leader),负责进行投票的发起和决议,更新系统状态
      » 学习者(learner),包括跟随者(follower)和观察者(observer),follower用于接受客户端请求并想客户端返回结果,在选主过程中参与投票
      » Observer可以接受客户端连接,将写请求转发给leader,但observer不参加投票过程,只同步leader的状态,observer的目的是为了扩展系统,提高读取速度
      » 客户端(client),请求发起方

        

         

      • Zookeeper的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协
         议。Zab协议有两种模式,它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者
       崩溃后,Zab就进入了恢复模式,当领导者被选举出来,且大多数Server完成了和leader的状态同步以后
        ,恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。

      • 为了保证事务的顺序一致性,zookeeper采用了递增的事务id号(zxid)来标识事务。所有的提议(
       proposal)都在被提出的时候加上了zxid。实现中zxid是一个64位的数字,它高32位是epoch用来标识
         leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch,标识当前属于那个leader的
       统治时期。低32位用于递增计数。
      • 每个Server在工作过程中有三种状态:
        LOOKING:当前Server不知道leader是谁,正在搜寻
        LEADING:当前Server即为选举出来的leader
        FOLLOWING:leader已经选举出来,当前Server与之同步

      其他文档:http://www.cnblogs.com/lpshou/archive/2013/06/14/3136738.html

    2、Zookeeper 的读写机制

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

    3、Zookeeper 的保证 

      » 更新请求顺序进行,来自同一个client的更新请求按其发送顺序依次执行
      » 数据更新原子性,一次数据更新要么成功,要么失败
      » 全局唯一数据视图,client无论连接到哪个server,数据视图都是一致的
      » 实时性,在一定事件范围内,client能读到最新数据

    4、Zookeeper节点数据操作流程

           

        注:1.在Client向Follwer发出一个写的请求

          2.Follwer把请求发送给Leader

          3.Leader接收到以后开始发起投票并通知Follwer进行投票

          4.Follwer把投票结果发送给Leader

          5.Leader将结果汇总后如果需要写入,则开始写入同时把写入操作通知给Leader,然后commit;

          6.Follwer把请求结果返回给Client

          

        • Follower主要有四个功能:
        • 1. 向Leader发送请求(PING消息、REQUEST消息、ACK消息、REVALIDATE消息);
        • 2 .接收Leader消息并进行处理;
        • 3 .接收Client的请求,如果为写请求,发送给Leader进行投票;
        • 4 .返回Client结果。
        • Follower的消息循环处理如下几种来自Leader的消息:
        • 1 .PING消息: 心跳消息;
        • 2 .PROPOSAL消息:Leader发起的提案,要求Follower投票;
        • 3 .COMMIT消息:服务器端最新一次提案的信息;
        • 4 .UPTODATE消息:表明同步完成;
        • 5 .REVALIDATE消息:根据Leader的REVALIDATE结果,关闭待revalidate的session还是允许其接受消息;
        • 6 .SYNC消息:返回SYNC结果到客户端,这个消息最初由客户端发起,用来强制得到最新的更新。

    5、Zookeeper leader 选举  

      • 半数通过
        – 3台机器 挂一台 2>3/2
        – 4台机器 挂2台 2!>4/2

      

      • A提案说,我要选自己,B你同意吗?C你同意吗?B说,我同意选A;C说,我同意选A。(注意,这里超过半数了,其实在现实世界选举已经成功了。

       但是计算机世界是很严格,另外要理解算法,要继续模拟下去。)
      • 接着B提案说,我要选自己,A你同意吗;A说,我已经超半数同意当选,你的提案无效;C说,A已经超半数同意当选,B提案无效。
      • 接着C提案说,我要选自己,A你同意吗;A说,我已经超半数同意当选,你的提案无效;B说,A已经超半数同意当选,C的提案无效。
      • 选举已经产生了Leader,后面的都是follower,只能服从Leader的命令。而且这里还有个小细节,就是其实谁先启动谁当头。

      

      

    6、zxid

      • znode节点的状态信息中包含czxid, 那么什么是zxid呢?
      • ZooKeeper状态的每一次改变, 都对应着一个递增的Transaction id, 该id称为zxid. 由于zxid的递增性质, 如果zxid1小于zxid2, 那么zxid1肯定先于zxid2发生.

       创建任意节点, 或者更新任意节点的数据, 或者删除任意节点, 都会导致Zookeeper状态发生改变, 从而导致zxid的值增加.

    7、Zookeeper工作原理

      » Zookeeper的核心是原子广播,这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式,它们分别是恢复模式和广播模式。

       当服务启动或者在领导者崩溃后,Zab就进入了恢复模式,当领导者被选举出来,且大多数server的完成了和leader的状态同步以后,恢复模式就结束了。

       状态同步保证了leader和server具有相同的系统状态

      » 一旦leader已经和多数的follower进行了状态同步后,他就可以开始广播消息了,即进入广播状态。这时候当一个server加入zookeeper服务中,它会在恢复模式下启动,

       发现leader,并和leader进行状态同步。待到同步结束,它也参与消息广播。Zookeeper服务一直维持在Broadcast状态,直到leader崩溃了或者leader失去了大部分

       的followers支持。

      » 广播模式需要保证proposal被按顺序处理,因此zk采用了递增的事务id号(zxid)来保证。所有的提议(proposal)都在被提出的时候加上了zxid。

       实现中zxid是一个64为的数字,它高32位是epoch用来标识leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch。低32位是个递增计数。

      » 当leader崩溃或者leader失去大多数的follower,这时候zk进入恢复模式,恢复模式需要重新选举出一个新的leader,让所有的server都恢复到一个正确的状态。 

      » 每个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的请求进行服务了

    8、数据一致性与paxos 算法  

      • 据说Paxos算法的难理解与算法的知名度一样令人敬仰,所以我们先看如何保持数据的一致性,这里有个原则就是:
      • 在一个分布式数据库系统中,如果各节点的初始状态一致,每个节点都执行相同的操作序列,那么他们最后能得到一个一致的状态。
      • Paxos算法解决的什么问题呢,解决的就是保证每个节点执行相同的操作序列。好吧,这还不简单,master维护一个
         全局写队列,所有写操作都必须 放入这个队列编号,那么无论我们写多少个节点,只要写操作是按编号来的,就能保证一
       致性。没错,就是这样,可是如果master挂了呢。
      • Paxos算法通过投票来对写操作进行全局编号,同一时刻,只有一个写操作被批准,同时并发的写操作要去争取选票,
       只有获得过半数选票的写操作才会被 批准(所以永远只会有一个写操作得到批准),其他的写操作竞争失败只好再发起一
       轮投票,就这样,在日复一日年复一年的投票中,所有写操作都被严格编号排 序。编号严格递增,当一个节点接受了一个
       编号为100的写操作,之后又接受到编号为99的写操作(因为网络延迟等很多不可预见原因),它马上能意识到自己 数据
       不一致了,自动停止对外服务并重启同步过程。任何一个节点挂掉都不会影响整个集群的数据一致性(总2n+1台,除非挂掉大于n台)。
      总结
      • Zookeeper 作为 Hadoop 项目中的一个子项目,是 Hadoop 集群管理的一个必不可少的模块,它主要用来控制集群中的数据,

       如它管理 Hadoop 集群中的 NameNode,还有 Hbase 中 Master Election、Server 之间状态同步等。\

       关于Paxos算法可以查看文章 Zookeeper全解析——Paxos作为灵魂

       推荐书籍:《从Paxos到Zookeeper分布式一致性原理与实践


    9、Observer  

      • Zookeeper需保证高可用和强一致性;
      • 为了支持更多的客户端,需要增加更多Server;
      • Server增多,投票阶段延迟增大,影响性能;
      • 权衡伸缩性和高吞吐率,引入Observer
      • Observer不参与投票;
      • Observers接受客户端的连接,并将写请求转发给leader节点;
      • 加入更多Observer节点,提高伸缩性,同时不影响吞吐率

    10、 为什么zookeeper集群的数目,一般为奇数个?

      •Leader选举算法采用了Paxos协议;
      •Paxos核心思想:当多数Server写成功,则任务数据写成功如果有3个Server,则两个写成功即可;如果有4或5个Server,则三个写成功即可。
      •Server数目一般为奇数(3、5、7)如果有3个Server,则最多允许1个Server挂掉;如果有4个Server,则同样最多允许1个Server挂掉由此,

        我们看出3台服务器和4台服务器的的容灾能力是一样的,所以为了节省服务器资源,一般我们采用奇数个数,作为服务器部署个数。

    11、Zookeeper 的数据模型 

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

    12、Zookeeper 的节点

      » Znode有两种类型,短暂的(ephemeral)和持久的(persistent)
      » Znode的类型在创建时确定并且之后不能再修改
      » 短暂znode的客户端会话结束时,zookeeper会将该短暂znode删除,短暂znode不可以有子节点
      » 持久znode不依赖于客户端会话,只有当客户端明确要删除该持久znode时才会被删除
      » Znode有四种形式的目录节点
      » PERSISTENT(持久的)
      » EPHEMERAL(暂时的)
      » PERSISTENT_SEQUENTIAL(持久化顺序编号目录节点)
      » EPHEMERAL_SEQUENTIAL(暂时化顺序编号目录节点)

    展开全文
  • Ingredient:
  • 本原创入门教程,涵盖ZooKeeper核心内容,通过实例和大量图表,结合实战,帮助学习者理解和运用,任何问题欢迎留言。 目录: zookeeper介绍与核心概念 安装和使用 ZooKeeper分布式锁实现 ZooKeeper框架Curator...
  • Zookeeper是什么官方文档上这么解释zookeeper,它是一个分布式服务框架,是Apache Hadoop 的一个子项目,它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务、状态同步服务、集群管理、...
  • RPC框架中有3个重要的角色: ...简单来讲,zookeeper可以充当一个服务注册表(Service Registry),让多个服务提供者形成一个集群,让服务消费者通过服务注册表获取具体的服务访问地址(IP+端口)去访...
  • zookeeper是什么 官方说辞:Zookeeper 分布式服务框架是Apache Hadoop 的一个子项目,它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如:统一命名服务、状态同步服务、集群管理、分布式应用配置项的...
  • zookeeper 分布式配置中心
  • zookeeper和dubbo的关系

    2016-04-29 16:50:08
     zookeeper用来注册服务和进行负载均衡,哪一个服务由哪一个机器来提供必需让调用者知道,简单来说就是ip地址和服务名称的对应关系。当然也可以通过硬编码的方式把这种对应关系在调用方业务代码中实现,但是如果...
  • zookeeper运维

    2019-01-13 22:59:34
    尽管zookeeper在编程上有很多的阱陷,API也非常的难用,但zookeeper服务本身可以说是很牢靠的了,所以在网上貌似关于运维的文章比较少。 但省心并不代表不会出麻烦,下面总结下zookeeper运维相关的东东。 重要的...
  • 由于公司年底要更换办公地点,所以最近投了一下简历,发现面试官现在很喜欢问dubbo、zookeeper和高并发等。由于公司没有使用dubbo,只知道dubbo是一个远程服务调用的分布式框架,zookeeper为分布式应用程序协调服务...
  • ZooKeeper服务命令:  在准备好相应的配置之后,可以直接通过zkServer.sh 这个脚本进行服务的相关操作 1. 启动ZK服务: sh bin/zkServer.sh start 2. 查看ZK服务状态: sh bin/zkServer.sh status 3. 停止ZK服务:...
  • 目录  一 .Zookeeper功能简介  二 . ZooKeeper基本概念 2.1 集群角色 2.2 集群节点分工 2.3 session 2.4 数据节点 2.5 状态信息 2.6 事物操作 2.7 Wa...
  • ZooKeeper原理及使用

    2014-08-07 17:47:06
    ZooKeeper是Hadoop Ecosystem中非常重要的...今天这篇文章分为三个部分来介绍ZooKeeper,第一部分介绍ZooKeeper的基本原理,第二部分介绍ZooKeeper提供的Client API的使用,第三部分介绍一些ZooKeeper典型的应用场景。
  • 最后发现线上的zookeeper的日志zookeeper.out 文件居然有6G,后来设置下日志为滚动输出,参考: http://blog.csdn.net/hengyunabc/article/details/19006911 但是改了之后,发现一天的日志量就是100多M,滚动日志...
  • 实现分布式锁目前有三种流行方案,分别为基于数据库、Redis、Zookeeper的方案,其中前两种方案网络上有很多资料可以参考,本文不做展开。我们来看下使用Zookeeper如何实现分布式锁。 什么是Zookeeper? ...
1 2 3 4 5 ... 20
收藏数 213,373
精华内容 85,349
关键字:

zookeeper