zookeeper原理与实践(一)----zookeeper的基本功能

  我们现在围绕两个问题来学习zookeeper:

      • 什么是zookeeper?
      • zookeeper基础知识
  1. 什么是zookeeper: zookeeper是hadoop下面的一个子项目,是一个分布式协调服务框架,这个解释其实是很抽象的。其实我觉得不用扯这些东西,通过zk的一些实践项目就可以很好的理解什么是zookeeper了。我们通过一个zk的实际例子来了解,基本所有公司都有这样的需求:在使用rpc进行服务调用的时候,我们更不关心现在提供服务的集群入口(比如:一个集群提供同一个服务,但是只有一个入口(进行实际服务调用,负载均衡等操作),并且这个入口会进行主从切换)是哪一个?那么我们应该怎么弄才能再第一时间获取到入口机器的变更呢?这样的需求我们就能使用zookeeper来提供一个命名服务,我们为这个服务提供一个name,并将它注册到zk中,每一次入口变更都会先到zk进行更改。这样就可以完全屏蔽服务集群的入口了。
  2. zookeeper基础知识:
      • zookeeper组成: 通常集群都存在master/slave架构,比如hadoop。但是zookeeper中却不是这种架构模式,它的组成可以分为三类

        • leader:    集群中的管理者,负责接收客户端的读写操作和消息分发。
        • follower:  集群中leader的随从,负责接收客户端的读操作,并进行leader选举的投票。
        • observe:  用于提高缓解zk的读操作压力,负责接收客户端的都操作,但是不参与leader投票。 
      • 会话: client与server端通过tcp长连接的形式进行通信,建立连接之后通过心跳进行状态检查,同时server端接收client的请求,client端接收server端的watch响应。
      • 数据节点: zookeeper中的数据是按照树状来进行排布的,类似于Linux目录结构,但是不存在文件夹与文件的区别,所有的元素都是节点,我们存储的数据也存放在节点中,节点又可以作为父节点容纳子节点。其中zk的数据节点可进行如下分类:
        • 持久节点: 就是一旦创建就不会因为客户端的连接与否而被删除,除非客户端主动进行删除。
        • 临时节点: 创建节点的生命周期与客户端的生命周期相同,即只能存活在客户端生命周期内。
        • 顺序节点: 就类似与我们平时使用的windows,同样的一个文件放在同一级目录下面会出现后面的编号。就是通过自动添加编号的方式来进行相同目录下不同文件的辨别。
      • 版本:  zookeeper中每个数据节点都存放有我们所需要的数据,并且每个数据都有一个stat数据,这个数据记录了这个znode上的三个版本,分别是version(当前节点的数据版本),cversion(当前znode子节点的版本),avresion(当前znode的ACL版本)。这些版本信息中version版本是保证分布式数据原子性的基础,这个我们后面也会详细的学习。
      • watcher: 我们在使用zk的时候,如果存在这样一种需求,就是客户端会对zk的数据进行缓存以减少对zk集群的访问压力,那么我们需要实时的获取数据的最新版本,那么现在就存在这样一个问题,当服务器端对一个数据进行更改的时候如何通过客户端来获取最新数据。针对这个需求,我们就有必要好好了解一下watcher,其工作的原理就是客户端需要在服务器端针对自己感兴趣的事件(比如:delete)进行watcher注册,当服务器端节点触发这个事件的时候,我们就会通知这些感兴趣的节点来进行数据更新。这就是大致的watcher的过程。
      • ACL: 上面我们提到数据节点的版本时,提到ACL,那么什么是ACL呢?ACL全称是Access Control list,访问控制列表,用来进行数据操作的权限控制。提供了以下几种访问控制权限:
        • create
        • read
        • write
        • delete
        • admin

  3.  zookeeper的特征:

      • 顺序一致性: 指的是同一个客户端发出的一系列请求会严格按照发送的顺序进行执行。
      • 原子性:  主要侧重于zookeeper能够保证在整个zk集群中所有机器都会提交一个事务。注意:这里指的是最终的状态,而不是提交的标准,因为zk commit 事务的时候,只要收到超过一半的节点返回ACK就执行commit。
      • 单一视图:  无论哪一个客户端连接得到的视图都相同,均为同一个视图。
      • 可靠性:  其实我个人对可靠性的理解是允许zk leader节点宕机,zk同样能对外提供服务。而看了以为大牛的博客是这样解释的:可靠性就是说如果一个事务被zk提交,那么事务引起的客户端的变化将会持续下去直到被修改。这个我觉得选择性接收吧。
      • 实时性: zk只能在一定时间内保证数据传递的实时性。     
时间: 2024-11-08 06:22:36

zookeeper原理与实践(一)----zookeeper的基本功能的相关文章

《从PAXOS到ZOOKEEPER分布式一致性原理与实践》pdf

下载地址:网盘下载 内容简介  · · · · · · <Paxos到Zookeeper:分布式一致性原理与实践>从分布式一致性的理论出发,向读者简要介绍几种典型的分布式一致性协议,以及解决分布式一致性问题的思路,其中重点讲解了Paxos和ZAB协议.同时,本书深入介绍了分布式一致性问题的工业解决方案--ZooKeeper,并着重向读者展示这一分布式协调框架的使用方法.内部实现及运维技巧,旨在帮助读者全面了解ZooKeeper,并更好地使用和运维ZooKeeper.全书共8章,分为五部分:第一

《从Paxos到Zookeeper:分布式一致性原理与实践》【PDF】下载

内容简介 Paxos到Zookeeper分布式一致性原理与实践从分布式一致性的理论出发,向读者简要介绍几种典型的分布式一致性协议,以及解决分布式一致性问题的思路,其中重点讲解了Paxos和ZAB协议.同时,本书深入介绍了分布式一致性问题的工业解决方案--ZooKeeper,并着重向读者展示这一分布式协调框架的使用方法.内部实现及运维技巧,旨在帮助读者全面了解ZooKeeper,并更好地使用和运维ZooKeeper.全书共8章,分为五部分:前一部分(第1章)主要介绍了计算机系统从集中式向分布式系统

[从Paxos到ZooKeeper][分布式一致性原理与实践]&lt;一&gt;

目录 分布式架构 从集中式到分布式 从ACID到CAP/BASE 一致性协议 2PC与3PC Paxos算法 Paxos的工程实践 Chubby Hypertable Zookeeper与Paxos 初始Zookeeper Zookeeper的ZAB协议 使用Zookeeper 部署与运行 客户端脚本 Java客户端API 开源客户端 Zookeeper的典型应用场景 Zookeeper技术内幕 系统模型 序列化与协议 科幻端 会话 服务器启动 leader选举 ... Zookeeper运维

ZooKeeper学习第七期---ZooKeeper一致性原理

转:http://www.cnblogs.com/sunddenly/p/4138580.html 一.ZooKeeper 的实现 1.1 ZooKeeper处理单点故障 我们知道可以通过ZooKeeper对分布式系统进行Master选举,来解决分布式系统的单点故障,如图所示. 图 1.1 ZooKeeper解决单点故障 那么我们继续分析一下,ZooKeeper通过Master选举来帮助分布式系统解决单点故障,保证该系统中每时每刻只有一个Master为分布式系统提供服务.也就是说分布式的单点问题

ZooKeeper原理分析

ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,它包含一个简单的原语集,分布式应用程序可以基于它实现同步服务,配置维护和命名服务等.Zookeeper是hadoop的一个子项目,其发展历程无需赘述.在分布式应用中,由于工程师不能很好地使用锁机制,以及基于消息的协调机制不适合在某些应用中使用,因此需要有一种可靠的.可扩展的.分布式的.可配置的协调机制来统一系统的状态.Zookeeper的目的就在于此.本文简单分析zookeeper的工作原理,对于如何使用zookeeper不是本

ZooKeeper原理及其在Hadoop和HBase中的应用

简介 ZooKeeper是一个开源的分布式协调服务,由雅虎创建,是Google Chubby的开源实现.分布式应用程序可以基于ZooKeeper实现诸如数据发布/订阅.负载均衡.命名服务.分布式协调/通知.集群管理.Master选举.分布式锁和分布式队列等功能. 基本概念 本节将介绍ZooKeeper的几个核心概念.这些概念贯穿于之后对ZooKeeper更深入的讲解,因此有必要预先了解这些概念. 集群角色 在ZooKeeper中,有三种角色: Leader Follower Observer 一

8.8.ZooKeeper 原理和选举机制

1.ZooKeeper原理 Zookeeper虽然在配置文件中并没有指定master和slave但是,zookeeper工作时,是有一个节点为leader,其他则为follower,Leader是通 过内部的选举机制临时产生的 2.ZooKeeper选举机制 2.1.概念 2.2. zk的选举机制(全新集群paxos):新搭建,无任何数据(通过myid) 2.3. 非全新集群的选举机制(数据恢复) 原文地址:https://www.cnblogs.com/yaboya/p/9149077.htm

zookeeper原理及搭建

zookeeper ? zookeeper 是什么? – ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务 ? ZooKeeper能干什么哪? – ZooKeeper是用来保证数据在集群间的事务性一致 ? zookeeper 应用场景 – 集群分布式锁 – 集群统一命名服务 – 分布式协调服务 ? zookeeper 角色与特性 – Leader: – 接受所有Follower的提案请求并统一协调发起提案的投票,负责与所有的Follower进行内部的数据交换 – Followe

详解Zookeeper原理与应用场景

Zookeeper 分布式协调服务 应用之处:发布.订阅,命名服务,分布式协调和分布式锁 对比 Chubby: Chubby 被定义为 分布式的锁服务 为分布式系统提供 松耦合.粗粒度 的分布式锁功能 其由两部分组成 提供数据的读写接口并管理相关配置数据的服务端 另一部分是客户端使用的 SDK 为对外提供稳定服务,每一个 Chubby 单元都由一组服务器组成,使用共识算法从集群中选举出主节点 实现原理: 文件系统: Zookeeper 也使用文件系统组织系统中存储的资源 /parent /par