ZooKeeper原理、应用与面经计算彩民之家论坛9066

2019-10-11 05:42 来源:未知

2)除B之外的实例得知创建znode失败,则向/current/leader注册watcher,并将自己角色标注为follower,开始执行follower相关的初始化工作。

监视是一种简单的机制,使客户端收到关于ZooKeeper集合中的更改的通知。客户端可以在读取特定znode时设置Watches。Watches会向注册的客户端发送任何znode更改的通知。Znode更改是与znode相关的数据的修改或znode的子项中的更改。只触发一次watches。如果客户端想要再次通知,则必须通过另一个读取操作来完成。当连接会话过期时,客户端将与服务器断开连接,相关的watches也将被删除。

二、ZooKeeper应用

Zookeeper客户端提供了基本的操作,比如,创建会话、创建节点、读取节点、更新数据、删除节点和检查节点是否存在等。但对于开发人员来说,Zookeeper提供的基本操纵还是有一些不足之处,比如Session超时之后没有实现重连机制、异常处理繁琐、Watcher是一次性等等。但是好在社区提供了两款十分强大的ZK客户端:ZKClientCurator

  • ZkClient是一个开源客户端,在Zookeeper原生API接口的基础上进行了包装,更便于开发人员使用。内部实现了Session超时重连,Watcher反复注册等功能。像dubbo等框架对其也进行了集成使用。
  • Curator是Netflix公司开源的一套Zookeeper客户端框架,和ZkClient一样,解决了非常底层的细节开发工作,包括连接重连、反复注册Watcher和NodeExistsException异常等。目前已经成为Apache的顶级项目。另外还提供了一套易用性和可读性更强的Fluent风格的客户端API框架。除此之外,Curator中还提供了Zookeeper各种应用场景(Recipe,如共享锁服务、Master选举机制和分布式计算器等)的抽象封装。

这两个客户端,熟练掌握其中的一种即可!下面以ZKClient为例,创建会话、创建节点、读取数据、更新数据、删除节点、检测节点等方面介绍ZkClient的使用。

在Haddop生态系统中,HBase、YARN和HDFS等系统,采用了类似的机制结局leader选举问题。

分布式应用的优点

一、原理篇

为什么需要ZooKeeper?现在分布式集群已经成为后台系统的主流部署方式,而集群部署和分布式的环境提供了强大服务的同事也增加了问题的复杂性,比如集群节点在相互通信时,A节点向B节点发送消息。A节点如果想知道消息是否发送成功,只能由B节点告诉A节点。那么如果B节点关机或者由于其他的原因脱离集群网络,问题就出现了。A节点不断的向B发送消息,并且无法获得B的响应。B也没有办法通知A节点已经离线或者关机。集群中其他的节点完全不知道B发生了什么情况,还在不断的向B发送消息。这时,你的整个集群就发生了部分失败的故障。Zookeeper不能让部分失败的问题彻底消失,但是它提供了一些工具能够让你的分布式应用安全合理的处理部分失败的问题。引自——【Zookeeper 入门】

Zookeeper是Hadoop分布式调度服务,用来构建分布式应用系统。构建一个分布式应用是一个很复杂的事情,一个分布式系统会有以下几大特性和需要解决的问题:

  • 分布性,项目会根据不同的功能拆分成不同的模块,部署成不同的服务放在不同的机器上。
  • 对等性,服务备份成对等的几个副本,相互之间都是对等的。
  • 并发性,多进程、多JVM
  • 缺乏全局时钟,节点有各自独立的时钟,如果有并发事务则需要有一个居中协调的调度器
  • 随机故障,可能来自于节点异常、通信故障、网络延时、网络分区

分布式系统中绕不开最重要CAP原则,又称CAP定理,指的是在一个分布式系统中,Consistency、 Availability、Partition tolerance,三者不可得兼,最多只能同时满足其中的两项。

之前在博客《分布式系统的事务探讨》中介绍过,简而言之就是:一致性是多个副本的结果一致性(广义上则可以延伸到分布式事务的转账问题),可用性则是请求在有限的时间内得到响应,分区容错性就是在网络分区故障的时候、仍可对外提供满足Consistency和Availability的服务。

在CAP理论的基础上,又进化出了BASE理论,P是一定需要的,剩下要做的就是在C和A之间进行平衡。BASE理论:即使无法做到强一致性,但分布式系统可以根据自己的业务特点,采用适当的方式来使系统达到最终的一致性

  • Basically Avaliable 基本可用。既然故障不可避免但要保证基本可用,则允许服务容错、降级、熔断等措施
  • Soft state 软状态。允许系统中的数据存在中间状态,允许延时,比如请求排队。
  • Eventually consistent 最终一致性。所有的数据在经过一段时间的数据同步后,最终能够达到一个一致的状态。

ZooKeeper是一种分布式协调服务,用于管理大型主机。ZooKeeper 的设计目标是将那些复杂且容易出错的分布式一致性服务封装起来,构成一个高效可靠的原语集。在分布式环境中协调和管理服务是一个复杂的过程,而ZooKeeper通过其简单的架构和API解决了这个问题,例如ZK提供了数据发布订阅、负载均衡、命名服务、Master选举、集群管理、配置管理、分布式队列和分布式锁等功能。

Zookeeper的数据保持在内存中,这就意味着它可以实现高吞吐量和低延迟的数据。另外,Zookeeper自己在处理协调的时候要复制多个主机,Zookeeper服务的组成部分必须彼此都知道彼此,它们维持了一个内存状态影像,连同事务日志和快照在一个持久化的存储中。只要大多数的服务器是可用的,Zookeeper服务就是可用的。

彩民之家论坛9066777 1ZK服务

特点总结:1、集群部署,容错性高。2、内存设计,高吞吐低延迟。3、特别适合读场景,性能好。4、临时节点设计,提供监听服务。

  • ZooKeeper 本身就是一个分布式程序(只要半数以上节点存活,ZooKeeper 就能正常服务)。为了保证高可用,最好是以**集群形态来部署,这样只要集群中大部分机器是可用的(能够容忍一定的机器故障),那么 ZooKeeper 本身仍然是可用的。
  • ZooKeeper 将数据保存在内存中,这也就保证了 高吞吐量和低延迟(但是内存限制了能够存储的容量不太大,此限制也是保持znode中存储的数据量较小的进一步原因)。
  • ZooKeeper 是高性能的。 在“读”多于“写”的应用程序中尤其地高性能,因为“写”会导致所有的服务器间同步状态。(“读”多于“写”是协调服务的典型场景。)
  • ZooKeeper有临时节点的概念。 当创建临时节点的客户端会话一直保持活动,瞬时节点就一直存在。而当会话终结时,瞬时节点被删除。持久节点是指一旦这个ZNode被创建了,除非主动进行ZNode的移除操作,否则这个ZNode将一直保存在Zookeeper上。
  • ZooKeeper 底层其实只提供了两个功能:①管理用户程序提交的数据;②为用户程序提交数据节点监听服务。

彩民之家论坛9066777 2基于ZooKeeper的leader选举

会话对于ZooKeeper的操作非常重要。一旦客户端连接到服务器,将建立会话并向客户端分配会话ID 。客户端以特定的时间间隔发送心跳以保持会话有效。如果ZooKeeper集合在超过服务器开启时指定的期间都没有从客户端接收到心跳,则它会判定客户端死机。会话超时通常以毫秒为单位。当会话由于任何原因结束时,在该会话期间创建的临时节点也会被删除。

改变节点数据、检测节点是否存在
public class ZkClientTest { public static void main(String[] args) throws InterruptedException { //创建会话 ZkClient zkClient = new ZkClient("127.0.0.1:2181", 5000); //创建节点 String path = "/zk-book"; zkClient.createPersistent(path,"123"); //监测节点数据变化 zkClient.subscribeDataChanges(path, new IZkDataListener() { @Override public void handleDataDeleted(String dataPath) throws Exception { System.out.println("Node "   dataPath   " deleted."); } @Override public void handleDataChange(String dataPath, Object data) throws Exception { System.out.println("Node "   dataPath   " changed, new data: "  data); } }); //读取节点数据 System.out.println(zkClient.readData; zkClient.writeData(path, "456"); Thread.sleep; System.out.println("Node exists :"   zkClient.exists; zkClient.delete; System.out.println("Node exists :"   zkClient.exists; }}

Demo引自——【ZooKeeper学习笔记-6---ZkClient使用】,该博客中有系统总结ZK应用,可以学习。

zk集群搭建可参考该文章:

注意!!!在zookeeper的选举过程中,为了保证选举过程最后能选出leader,就一定不能出现两台机器得票相同的僵局,所以一般的,要求zk集群的server数量一定要是奇数,也就是2n 1台,并且,如果集群出现问题,其中存活的机器必须大于n 1台,否则leader无法获得多数server的支持,系统就自动挂掉。所以一般是3个或者3个以上节点。因此有些面试考察的时候会问各种挂掉的情况,只要记住:过半存活就能保证工作,否则系统就挂掉了。另外ZK集群不支持动态扩容,Zookeeper在这方面不太好,扩容只能采用以下两种方式:

  • 全部重启:关闭所有Zookeeper服务,修改配置之后启动。不影响之前客户端的会话。
  • 逐个重启:顾名思义。这是比较常用的方式。

基于ZooKeeper的leader选举流程如下:

Watches

.ZK数据模型

ZooKeeper包含一个树形的数据模型——Znode。一个znode中包含了存储的数据和 ACL(Access Control List)。ZooKeeper的设计适合存储少量的数据,并不适合存储大量数据,所以znode的存储限制最大不超过1M。

ZK数据的访问被定义成原子性的。即一个客户端访问一个znode时,不会只得到一部分数据;客户端访问数据要么获得全部数据,要么读取失败,什么也得不到。相似的,写操作时,要么写入全部数据,要么写入失败,什么也写不进去。ZooKeeper能够保证写操作只有两个结果,成功和失败。绝对不会出现只写入了一部分数据的情况。(区别于数据流式读取的HDFS)

ZooKeeper通过path来定位znode,使用斜杠'/'来表示路径,这个和Unix系统定位文件一样。但是,znode的路径只能使用绝对路径,而不能像Unix系统一样使用相对路径,即Zookeeper不能识别../和./这样的路径。

本文从原理和实现角度介绍如何使用ZooKeeper解决常见的分布式问题,包括leader选举、分布式队列、负载均衡等。基于ZooKeeper实现leader选举的基本思想是,让各个参与竞选的实例同时在ZooKeeper上创建指定的znode,比如/current/leader,谁创建成功则谁竞选成功,并将自己的信息(host、port)写入该znode数据域,之后其他竞选者向该znode注册watcher,以便当前leader出现故障时,第一时间再次参与竞选,具体如图所示:

分布式应用程序提供了很多好处,但它们也抛出了一些复杂和难以解决的挑战。ZooKeeper通过其简单的架构和API解决了这个问题。ZooKeeper允许开发人员专注于核心应用程序逻辑,而不必担心应用程序的分布式特性。

.会话

在 ZooKeeper 中,一个客户端连接是指客户端和服务器之间的一个 TCP 长连接。客户端启动的时候,首先会与服务器建立一个 TCP 连接,从第一次连接建立开始,客户端会话的生命周期也开始了。通过这个连接,客户端能够通过心跳检测与服务器保持有效的会话,也能够向Zookeeper服务器发送请求并接受响应,同时还能够通过该连接接收来自服务器的Watch事件通知。ZK会话在整个运行期间的生命周期中,会在不同的会话状态之间切换,这些状态包括:CONNECTING、CONNECTED、RECONNECTING、RECONNECTED、CLOSE

1)各实例启动后,尝试在ZooKeeper上创建ephemeral类型znode节点/current/leader,假设实例B创建成功,则将自己的信息写入该znode,并将自己的角色标注为leader,开始执行leader相关的初始化工作。

分布式应用的挑战

.ACL权限控制

ACL机制,表示为scheme:id:permissions,第一个字段表示授权策略,第二个id表示用户,permissions表示相关权限(如只读,读写,管理等)。这个在实际种可能用到较少,了解一下即可。

  • 顺序一致性: 从同一客户端发起的事务请求,最终将会严格地按照顺序被应用到 ZooKeeper 中去。
  • 原子性: 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的,即要么整个集群中所有的机器都成功应用了某一个事务,要么都没有应用。
  • 单一系统映像 : 无论客户端连到哪一个 ZooKeeper 服务器上,其看到的服务端数据模型都是一致的。
  • 可靠性: 一旦一次更改请求被应用,更改的结果就会被持久化,直到被下一次更改覆盖。

生产中ZK是以集群的形式进行部署的,分为三类角色,Leader是集群工作机制中的核心,事务请求的唯一调度和处理者,保证集群事务处理的顺序性,集群内部个服务器的调度者(管理follower,数据同步)。Follower是集群工作机制中的跟随者处理非事务请求,转发事务请求给Leader参与事务请求proposal投票,参与leader选举投票。还有Observer 观察者,和follower功能相同,但不参与任何形式投票。

彩民之家论坛9066777 3ZK集群

集群工作流程:Zookeeper 客户端会随机连接到 Zookeeper 集群的一个节点,如果是读请求,就直接从当前节点中读取数据;如果是写请求,那么节点就会向 leader 提交事务,leader 会广播事务,只要有超过半数节点写入成功,该写请求就会被提交。但是考虑以下特殊情况,ZK集群该如何工作呢?

  • 主从架构下,leader 崩溃,数据一致性怎么保证?
  • 选举 leader 的时候,整个集群无法处理写请求的,如何快速进行 leader 选举?

这个时候需要Zab协议出场了:

ZAB 协议是为分布式协调服务 ZooKeeper 专门设计的一种支持崩溃恢复的原子广播协议。在 ZooKeeper 中,主要依赖 ZAB 协议来实现分布式数据一致性,基于该协议,ZooKeeper 实现了一种主备模式的系统架构来保持集群中各个副本之间的数据一致性。

Zab协议核心是在整个zookeeper集群中只有一个节点——leader将所有客户端的写操作转化为事务( 提议proposal )。leader节点在数据写完之后,将向所有的follower节点发送数据广播请求,等所有的follower节点的反馈,在zab协议中,只要超过半数follower节点反馈ok,leader节点会向所有follower服务器发送commit消息,将leader节点上的数据同步到follower节点之上。

Zab周期:正常情况下当客户端对zk有写的数据请求时,leader节点会把数据同步到follower节点,这个过程其实就是消息的广播模式;在新启动的时候,或者leader节点奔溃的时候会要选举新的leader,选好新的leader之后会进行一次数据同步操作,整个过程就是奔溃恢复。整个过程其实可以分成两部分。第一的消息广播模式,第二是崩溃恢复模式。

彩民之家论坛9066777 4Zab周期

  • 消息广播:Zab协议中的leader等待follower的ack反馈,只要半数以上的follower成功反馈就好,不需要收到全部的follower反馈。zookeeper中数据副本的同步方式与2PC提交类似,但二阶段提交的要求协调者必须等到所有的参与者全部反馈ACK确认消息后,再发送commit消息。要么全部成功要么全部失败。二阶段提交会产生严重阻塞问题,但Paxos和Zab只需要半数以上就可以确定。为了进一步防止阻塞,leader服务器与每个follower之间都有一个单独的队列进行收发消息,使用队列消息可以做到异步解耦,leader和follower之间只要往队列中发送了消息即可,如果使用同步方式容易引起阻塞,性能上要下降很多。

  • 奔溃恢复(也是快速选举算法和流程实现):1、每个Server会发出一个投票,第一次都是投自己。投票信息:(myid,ZXID)。2、收集来自各个服务器的投票。3、处理投票并重新投票,处理逻辑:优先比较ZXID,然后比较myid。4、统计投票,只要超过半数的机器接收到同样的投票信息,就可以确定leader。5、改变服务器状态

因此上面两个问题中,Leader挂掉以后的数据一致性的问题,答案可以这么来总结:

  • 主从架构下,leader 崩溃,数据一致性怎么保证?leader 崩溃之后,集群会选出新的 leader,然后就会进入恢复阶段,新的 leader 具有所有已经提交的提议,因此它会保证让 followers 同步已提交的提议,丢弃未提交的提议(以 leader 的记录为准),这就保证了整个集群的数据一致性。
  • 选举 leader 的时候,整个集群无法处理写请求的,如何快速进行 leader 选举?这是通过 Fast Leader Election 实现的,leader 的选举只需要超过半数的节点投票即可,这样不需要等待所有节点的选票,能够尽早选出 leader。

——【Zookeeper ZAB 协议分析】

3)系统正常运行,知道实例B因故障退出,此时znode节点/current/leader被ZooKeeper删除,其他follower收到节点被删除的事情,重新转入步骤1,开始新一轮leader选举。

1.分布式协调过程操作简单上手快2.同步 - 服务器进程之间的相互排斥和协作。3.有序的消息4.序列化 - 根据特定规则对数据进行编码。确保应用程序运行一致。这种方法可以在MapReduce中用来协调队列以执行运行的线程。5.可靠性 -通过集群来保证可靠性6.原子性 - 数据转移完全成功或完全失败,但没有事务是部分的。

会话创建、节点创建、获取子节点、删除节点
public class ZkClientTest { public static void main(String[] args) throws IOException,InterruptedException { //创建会话 ZkClient zkClient = new ZkClient("127.0.0.1:2181", 5000); String path = "/zk-book"; //监测子节点变化 zkClient.subscribeChildChanges(path, new IZkChildListener() { @Override public void handleChildChange(String parentPath, List<String> currentChild) throws Exception { System.out.println(parentPath   " 's child changed ,currentChilds: "   currentChild); } }); //创建节点 zkClient.createPersistent; Thread.sleep; System.out.println(zkClient.getChildren; Thread.sleep; zkClient.createPersistent(path   "/c1"); Thread.sleep; System.out.println(zkClient.getChildren; Thread.sleep; zkClient.createPersistent(path   "/c2","123"); Thread.sleep; System.out.println(zkClient.getChildren; //删除节点 Thread.sleep; zkClient.delete(path   "/c1"); Thread.sleep; System.out.println(zkClient.getChildren; zkClient.delete(path   "/c2"); System.out.println(zkClient.getChildren; Thread.sleep; }} 
  • 竞争条件 - 两个或多个机器尝试执行特定任务,实际上只需在任意给定时间由单个机器完成。例如,共享资源只能在任意给定时间由单个机器修改。
  • 死锁 - 两个或多个操作等待彼此无限期完成。
  • 不一致 - 数据的一致性。
.节点Znode
  • 1、Znode有两种类型:短暂(ephemeral)(create -e /app1/test1 “test1” 客户端断开连接zk删除ephemeral类型节点) 生命周期和客户端会话绑定,旦客户端会话失效,那么这个客户端创建的所有临时节点都会被移除。持久(persistent) (create -s /app1/test2 “test2” 客户端断开连接zk不删除persistent类型节点)

  • 2、Znode有四种形式的目录节点(默认是persistent )PERSISTENTPERSISTENT_SEQUENTIALEPHEMERALEPHEMERAL_SEQUENTIAL

  • 3、创建znode时设置顺序标识,znode名称后会附加一个值,顺序号是一个单调递增的计数器,由父节点维护;同时,顺序号可以被用于为所有的事件进行全局排序,这样客户端可以通过顺序号推断事件的顺序

命名服务 - 按名称标识集群中的节点。它类似于DNS,但仅对于节点。配置管理 - 加入节点的最近的和最新的系统配置信息。集群管理 - 实时地在集群和节点状态中加入/离开节点。选举算法 - 选举一个节点作为协调目的的leader。锁定和同步服务 - 在修改数据的同时锁定数据。

.Watcher

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

但是请注意watch机制官方说明:一个Watch事件是一个一次性的触发器,当被设置了Watch的数据发生了改变的时候,则服务器将这个改变发送给设置了Watch的客户端,以便通知它们。不支持用持久Watcher的原因很简单,如果Watcher的注册是持久的,那么必然导致服务端的每次数据更新都会通知到客户端——这在数据变更非常频繁且监听客户端特别多的场景下,ZooKeeper无法保证性能。

ZooKeeper的好处

三、面经

Zookeeper是什么框架?应用场景Paxos算法& Zookeeper使用协议选举算法和流程Zookeeper有哪几种节点类型Zookeeper对节点的watch监听通知是永久的吗?部署方式?集群中的机器角色都有哪些?集群最少要几台机器?集群如果有3台机器,挂掉一台集群还能工作吗?挂掉两台呢?集群支持动态添加机器吗?

Zookeeper 入门Zookeeper ZAB 协议分析ZK系列专栏,尤其推荐 Zookeeper 3、Zookeeper工作原理可能是全网把 ZooKeeper 概念讲的最清楚的一篇文章

Client客户端,我们的分布式应用集群中的一个节点,从服务器访问信息。对于特定的时间间隔,每个客户端向服务器发送消息以使服务器知道客户端是活跃的。Server服务器,我们的ZooKeeper总体中的一个节点,为客户端提供所有的服务。向客户端发送确认码以告知服务器是活跃的。ZooKeeper Service服务器组形成服务器组。所需的最小节点数为3。Leader服务器主节点,负责客户端的write类型的请求。Leader在服务启动时被选举。Follower 负责客户端的read类型请求,并可以参与Leader的选举

让我们分析如何在ZooKeeper集合中选举leader节点。考虑一个集群中有N个节点。leader选举的过程如下:

ZooKeeper是一种分布式协调服务。在分布式环境中协调和管理服务是一个复杂的过程。

Znode的类型

一个znode对应着一个客户端,每个客户端都可以在ZooKeeper文件系统中进行增删改查的文件操作,创建属于自己的znode文件节点,下图描述了用于内存表示的ZooKeeper文件系统的树结构。

Apache ZooKeeper是由集群使用的一种服务,用于在自身之间协调,并通过稳健的同步技术维护共享数据。ZooKeeper本身是一个分布式应用程序,为写入分布式应用程序提供服务。ZooKeeper提供的常见服务如下 :

  • 1.所有节点创建具有相同路径 /app/leader_election/guid_ 的顺序、临时节点。ZooKeeper集合将附加10位序列号到路径,创建的znode将是 /app/leader_election/guid_0000000001,/app/leader_election/guid_0000000002等。
  • 2.对于给定的实例,在znode中创建最小数字的节点成为leader,而所有其他节点是follower。
  • 3.每个follower节点监视下一个具有最小数字的znode。例如,创建znode/app/leader_election/guid_0000000008的节点将监视znode/app/leader_election/guid_0000000007,创建znode/app/leader_election/guid_0000000007的节点将监视znode/app/leader_election/guid_0000000006。
  • 4.如果leader关闭,则其相应的znode/app/leader_electionN会被删除。下一个在线follower节点将通过监视器获得关于leader移除的通知。下一个在线follower节点将检查是否存在其他具有最小数字的znode。如果没有,那么它将承担leader的角色。否则,它找到的创建具有最小数字的znode的节点将作为leader。
  • 5.类似地,所有其他follower节点选举创建具有最小数字的znode的节点作为leader。leader选举是一个复杂的过程,但ZooKeeper服务使它非常简单。

ZooKeeper数据模型中的每个znode都维护着一个 stat 结构。一个stat仅提供一个znode的元数据。它由版本号,操作控制列表,时间戳和数据长度组成。

  • 持久节点 - 即使在创建该特定znode的客户端断开连接后,持久节点仍然存在。默认情况下,所有znode都是持久的。
  • 临时节点 - 客户端活跃时,临时节点就是有效的。当客户端与ZooKeeper集合断开连接时,临时节点会自动删除。因此,只有临时节点不允许有子节点。如果临时节点被删除,则下一个合适的节点将填充其位置。临时节点在leader选举中起着重要作用。
  • 顺序节点 - 顺序节点可以是持久的或临时的。当一个新的znode被创建为一个顺序节点时,ZooKeeper通过将10位的序列号附加到原始名称来设置znode的路径。例如,如果将具有路径 /myapp 的znode创建为顺序节点,则ZooKeeper会将路径更改为 /myapp0000000001 ,并将下一个序列号设置为0000000002。如果两个顺序节点是同时创建的,那么ZooKeeper不会对每个znode使用相同的数字。顺序节点在锁定和同步中起重要作用。

彩民之家论坛9066777 549a262f02991463c5c91ac2d46ceb2b3.png

看看下面的图表。它描述了ZooKeeper的“客户端-服务器架构”。

  • 可靠性 - 单个或几个系统的故障不会使整个系统出现故障。
  • 可扩展性 - 可以在需要时增加性能,通过添加更多机器,在应用程序配置中进行微小的更改,而不会有停机时间。
  • 透明性 - 隐藏系统的复杂性,并将其显示为单个实体/应用程序。

彩民之家论坛9066777 6201612291345162031.jpg

Znode被分为持久(persistent)节点,顺序(sequential)节点和临时(ephemeral)节点。

命名服务通过ZooKeeper默认的文件系统得到解决配置管理和集群管理通过znode的数据存储得到解决选举算法和锁服务通过ZooKeeper的顺序节点的不重名得到解决

每个znode互相之间可以通过和ZooKeeper连接session来watch其他znode或者整个文件系统,来达到分布式环境下的消息联通。其中两个重要概念就是session和watchSessions

版权声明:本文由彩民之家高手论坛发布于编程技术,转载请注明出处:ZooKeeper原理、应用与面经计算彩民之家论坛9066