读《分布式一致性原理》系统模型

在本节中,我们先从数据模型,节点特性,版本,watcher和ACL五个方面来了解zookeeper系统模型。

数据模型

事务ID

狭义的事务通常指的是数据库事务,,一般包括一系列对数据库有序的读写操作,这些数据库事务所具有的ACID特性,

即原子性,一致性,隔离性,持久性。

在zookeeper中,事务是指能够改变zookeeper服务器状态的操作,我们称之为事物操作或更新操作,一般包括数据节点的

创建与删除,数据节点内容的更新,客户端会话创建与失效等操作。对于每一个事务请求,zookeeper都会为其分配一个

全局的唯一的事务ID,用ZXID来表示,通常是一个64位的数字。每一个ZXID对应一次更新操作,从这些ZXID中可以间接的

识别zookeeper处理这些更新操作请求全局顺序。

节点类型

1.持久节点(PERSISTENT)

所谓持久节点,是指在节点创建后,就一直存在,直到有删除操作来主动清除这个节点——不会因为创建该节点的客户端会话失效而消失。

2.持久顺序节点(PERSISTENT_SEQUENTIAL)

这类节点的基本特性和上面的节点类型是一致的。额外的特性是,在ZK中,每个父节点会为他的第一级子节点维护一份时序,会记录每个子节点创建的先后顺序。基于这个特性,在创建子节点的时候,可以设置这个属性,那么在创建节点过程中,ZK会自动为给定节点名加上一个数字后缀,作为新的节点名。这个数字后缀的范围是整型的最大值。

在创建节点的时候只需要传入节点 “/test_”,这样之后,zookeeper自动会给”test_”后面补充数字。

3.临时节点(EPHEMERAL)

和持久节点不同的是,临时节点的生命周期和客户端会话绑定。也就是说,如果客户端会话失效,那么这个节点就会自动被清除掉。注意,这里提到的是会话失效,而非连接断开。另外,在临时节点下面不能创建子节点。

这里还要注意一件事,就是当你客户端会话失效后,所产生的节点也不是一下子就消失了,也要过一段时间,大概是10秒以内,可以试一下,本机操作生成节点,在服务器端用命令来查看当前的节点数目,你会发现客户端已经stop,但是产生的节点还在。

4.临时顺序节点(EPHEMERAL_SEQUENTIAL)

此节点是属于临时节点,不过带有顺序,客户端会话结束节点就消失。下面是一个利用该特性的分布式锁的案例流程。

状态信息

我们可以针对zookeeper进行节点的创建和内容的更新,每个节点存储内容外还存储一些状态信息。我们可以用get命令来获取状态信息。

Stat类包含了zookeeper上一个数据节点的所有状态信息。

版本——保证分布式数据原子性操作

zookeeper中为数据节点引入了版本的概念,每个数据节点都具有三种类型的版本信息,对数据节点的任何操作更新操作

都会引起版本号的变化。

zookeeper中版本概念和传统软件的版本有很大的区别,它表示的是对数据的数据内容,子节点列表,或是节点ACL信息的修改次数。

在一个数据节点/zk-book被创建完毕之后,节点的version值是0,表示的含义是“当前节点自从创建之后,被更改的次数为0”;如果对该及节点的内容进行更新,那么该节点的version就会变为1.version强调的是变更次数,即使内容没有改变,version次数也会增加。

悲观锁,又称作悲观并发控制,是数据库中一种非常典型且严格的并发控制策略。具有强烈的独占和排他性。能够有效的避免不同事务对同一数据并发更新而造成的数据一致性问题。

乐观锁

我们其实可以把一个乐观锁控制的事务分成三个阶段:读取数据,写入效验,数据写入。

其中写入效验阶段是整个悲观所控制的关键所在。在写入校验阶段,事务会检查数据在读取阶段后是否

有其它事务对数据进行更新过,以确保数据更新的一致性。JDK中乐观锁的实现——CAS。

zookeeper服务器的PreRequestProcessor处理器类中,每一个数据更新请求都会进行如下检查。

Watcher——数据变更通知

在zookeeper中,接口类Watcher用于表示一个标准的事件处理器,其定义了时间通知的相关逻辑,包含keeperState和EventType

两个枚举类,分别代表通知状态和事件类型,同事定义了事件的回调方法:process(watchedEvent event)。

watcher事件

同一个事件类型在不同的通知状态中所代表的含义有所不同

对于AuthFailed这个时间,需要注意的地方是,它的出发条件并不是简简单单因为当前客户端会话没有权限,而是授权失败。

回调方法

process()方法是watcher接口中的一个回调方法,当zookeeper向哭护短发送wacher事件通知时,客户端就会对应响应的Process方法进行回调

提到wachedEvent,不得不讲WatcherEvent实体。笼统来讲两者表示的是同一个事物,都是对服务端事件的封装。不同的是,wahchedEvent是一个逻辑是件

用于服务端和客户端执行过程中所需的逻辑对象,而watcherEvent实现了序列化接口可以用于网络传出。

服务端在生成watchedEvent事件之后会调用getWrapped方法将自己包装成一个可序列化的watcherEvent事件,以便通过网络传输到客户端。客户端

接受到服务端的这个事件后,会首先将watcherEvent事件还原成一个watchedEvent事件,并传递个Process方法处理。

工作机制

zookeeper的watcher机制,总的来说可以概括为以下三个过程:客户端注册Watcher,服务端处理watcher,客户端回调watcher

客户端注册wacher

服务端处理流程和客户端回调流程可以具体查看此书先关章节。

Watcher特性

一次性:一旦一个watcher被触发,zookeeper就会将其从相应的存储中移除。

客户端串行执行:客户端watcher回调的过程是一个串行同步的过程。这为我们保证了顺序。

轻量:WatchedEvent是最小通知单元,只包含是三部分:通知状态,事件类型,节点路径。

ACL——保障数据的安全

从三个方面来理解ACL机制,分别是:权限模式,授权对象和权限

通常使用“scheme:id:permission”来表示一个有效的ACL信息。

权限模式:Scheme

权限模式用来确定权限验证过程中使用的检验策略。在zookeeper中,开发人员使用最多是一下四种权限模式。

IP

IP模式通过IP地址粒度来进行权限控制,例如配置了“ip:192.168.60.64”,即表示权限控制都是针对这个IP地址的。

同时,IP模式也支持按照网段的方式配置。例如“ip:192.168.0.1/24”表示针对192.168.0.*这个ip段进行权限控制。

Digest

Digest是最常用的权限控制模式,也更符合我们对于权限控制的认识,其以类是与“”username:password”形式

的权限标示来进行权限配置。便于区分不通应用来进行权限控制。

World

world是一种最开放的权限控制模式,从其名字中也可以看出,事实上这种权限控制的方式机会没有任何作用。

数据节点的访问权限对所有用户开放,即所有用户可以不进行任何权限效验的情况下操作zookeeper上的数据。另外,world模式也可以看做是一种特殊的Digest模式,它只是一个权限表示,即“world:anyone”;

Super

Super模式,顾名思义就是超级用户的意思,是一种特殊的Digest模式,在Super模式下,超级用户可以对任意

zookeeper上的数据节点进行任何操作。

授权对象:ID

授权对象指的是权限赋予的用户或一个指定实体,例如IP地址或是 机器等。在不同的权限模式下,授权对象时不同的。

权限:Permission

权限就是指通过权限检查后可以被允许执行的操作。在zookeeper中,所有对数据的操作权限分为以下五大类:

CREATE:数据节点的创建权限,允许授权对象在该数据节点下创建子节点。

DELETE:子节点的删除权限,允许授权对象删除该数据节点的子节点。

READ:数据节点的读取权限,允许授权对象访问该数据节点并读取其内容或子节点列表等。

WRITE:数据节点的权限更新,允许授权对象对该数据节点进行更新操作

ADMIN:数据节点的管理权限,允许授权对象对该数据节点进行ACL相关权限的设置操作。

ACL管理

设置ACL

通过zkCli脚本登陆zookeeper服务器后,可以通过两种方式进行ACL设置。

一种是在数据节点创建的同时进行ACL权限的设置。命令格式如下:

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

另一种方式则是使用setACL命令单独对已经存在的数据节点进行ACL设置:

setAcl path acl

具体使用如下

Super模式的用法

如果一个持久数据节点包含了ACL权限控制,而其他创建者客户端已经退出或已经不再使用,

那么这些数据节点该如何清理呢?这个时候,就乣在ACL的super模式下,使用超级管理员权限来进行

权限处理了。要使用超级管理员权限,首先需要在zookeeper服务器上开启super模式。该方法在zook

服务器启动的时候,添加如下系统属性:

其中“foo”代表了一个超级管理员的用户名;密码是可变的,由zookeeper

的系统管理员进行自主配置。此例中使用的是“foo:zk-book”的编码。

完成对zookeeper服务器的SUper模式的开启后,就可以在应用程序中使用了。

从上面的输出结果中,我们可以看出,由于“foo:zk-book”是一个超级管理员账户,因此能够针对一个受限控制的数据及诶单zk-book随意进行操作

原文地址:https://www.cnblogs.com/duan2/p/9095935.html

时间: 2024-08-02 00:48:02

读《分布式一致性原理》系统模型的相关文章

读<分布式一致性原理>初识zookeeper

zookeeper是什么 zookeeper是一个典型的分布式数据一致性的解决方案,分布式应用程序可以基于它实现诸如:数据发布/订阅,负载均衡,命名服务,分布式协调/通知 ,集群管理,Master选举,分布式锁和分布式队列等功能.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章)主要介绍了计算机系统从集中式向分布式系统

&lt;从PAXOS到ZOOKEEPER分布式一致性原理与实践&gt;读书笔记-ZAB协议

本文属于分布式系统学习笔记系列,上一篇笔记整理了paxos算法,本文属于原书第四章,梳理zookeeper的目标特性及ZAB协议. 1.介绍zookeeper 1.1ZooKeeper保证一致性特性 ZooKeeper是一个典型的分布式数据一致性的解决方案,分布式程序可以基于它实现诸如数据发布/订阅.负载均衡.命名服务.分布式协调通知.集群管理.master选举.分布式锁.分布式队列等功能.ZooKeeper可以保证如下分布式一致性特性. 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运维

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

Overview 在<一>有介绍到,一个分布式系统的架构设计,往往会在系统的可用性和数据一致性之间进行反复的权衡,于是产生了一系列的一致性协议. 为解决分布式一致性问题,在长期的探索过程中,涌现了一大批经典的一致性协议和算法,其中最著名的就是二阶段提交协议.三阶段提交协议和Paxos算法了. 2PC与3PC 分布式系统中,每个机器节点虽然都能明确知道自己在进行事务操作过程中的结果是失败or成功,但却无法直接获取到其他分布式节点的操作结果. 因此,当一个事务操作需要跨越多个分布式节点的时候,为了

《从Paxos到ZooKeeper 分布式一致性原理与实践》读书笔记

一.分布式架构 1.分布式特点 分布性 对等性.分布式系统中的所有计算机节点都是对等的 并发性.多个节点并发的操作一些共享的资源 缺乏全局时钟.节点之间通过消息传递进行通信和协调,因为缺乏全局时钟,很难定义两个事件谁先谁后 故障总是会发生.系统设计时,需要考虑到任何异常情况 2.分布式环境的各种问题 通信异常.分布式系统中的某些节点之间无法正常通信 网络分区.这有部分节点可以正常通信,有些无法正常通信.这种现象称为网络分区,也称为"脑裂" 三态.节点之间的一次通信存在三种状态:成功.失

从Paxos到Zookeeper 分布式一致性原理与实践(一)

1.分布式一致性问题 假设客户端C1将系统的K由V1更新为V2,但客户端C2无法立即读取到K的最新值,需要在一段时间才能读取到.-------数据库之间复制的延迟问题. 数据复制需求:1.为了增加系统的可用性,以防止单点故障引起的系统不可用.2.提高系统的整体性能,通过负载均衡技术,能够让分布在不同地方的数据副本都能够为用户提供服务. 所谓分布式一致性问题,是指分布式环境中引入数据复制机制后,不同数据节点间可能出现的,并无法依靠计算机应用程序自身解决的数据不一致情况.简单地讲,数据一致性就是指在

2月22日 《从Paxos到Zookeeper 分布式一致性原理与实践》读后感

工作中使用的场景: 工作中使用dubbo微服务,其中注册中心是由zk提供的,于是课余时光就读了此本zk经典之作 节点名为java接口的类名 节点下包括了服务提供者,消费者等子节点 提供者: 消费者: 由于是最底层微服务,所以消费的注册的比较多 zk的特点: 分布式一致性的解决方案,包括:顺序一致性,原子性,单一视图,可靠性,实时性 zk的基本概念: 集群角色:not Master/Slave,is Leader/Follower/Observer 会话:TCP长连接 数据节点(Znode) 版本