`
uule
  • 浏览: 6348866 次
  • 性别: Icon_minigender_1
  • 来自: 一片神奇的土地
社区版块
存档分类
最新评论

zookeeper选举算法

 
阅读更多

这可能是把ZooKeeper概念讲的最清楚的一篇文章

ZooKeeper基本原理

Zookeeper的Leader选举-选举过程介绍比较清晰(重要) 

 

顺序访问

对于来自客户端的每个更新请求,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(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 协议: 

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

 

Zookeeper Server接收到一次写request,如果是follower,会转发给leader,Leader执行请求并通过Transaction的形式广播这次执行。Zookeeper集群如何决定一个Transaction是否被commit执行?

通过“两段提交协议”(a two-phase commit):

 

1、Leader给所有的follower发送一个PROPOSAL消息(提案消息)

2、一个follower接收到这次PROPOSAL消息,写到磁盘,发送给leader一个ACK消息,告知已经收到。

3、当Leader收到法定人数(quorum)的follower的ACK时候,发送commit消息执行。

 

Zab协议保证:

 

1、如果leader以T1和T2的顺序广播,那么所有的Server必须先执行T1,再执行T2。

2、如果任意一个Server以T1、T2的顺序commit执行,其他所有的Server也必须以T1、T2的顺序执行。

 

“两段提交协议”最大的问题是如果Leader发送了PROPOSAL消息后crash或暂时失去连接,会导致整个集群处在一种不确定的状态(follower不知道该放弃这次提交还是执行提交)。Zookeeper这时会选出新的leader,请求处理也会移到新的leader上,不同的leader由不同的epoch标识。切换Leader时,需要解决下面两个问题:

1. Never forget delivered messages

Leader在COMMIT投递到任何一台follower之前crash,只有它自己commit了。新Leader必须保证这个事务也必须commit。

 

2. Let go of messages that are skipped

Leader产生某个proposal,但是在crash之前,没有follower看到这个proposal。该server恢复时,必须丢弃这个proposal。

 

Zookeeper会尽量保证不会同时有2个活动的Leader,因为2个不同的Leader会导致集群处在一种不一致的状态,所以Zab协议同时保证:

 

在新的leader广播Transaction之前,先前Leader commit的Transaction都会先执行。

在任意时刻,都不会有2个Server同时有法定人数(quorum)的支持者。

这里的quorum是一半以上的Server数目,确切的说是有投票权力的Server(不包括Observer)。

 

 

ZooKeeper的工作原理

 

在zookeeper的集群中,各个节点共有下面3种角色和4种状态:

 

角色:leader,followerobserver

状态:leadingfollowingobservinglooking

 

Zookeeper的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议(ZooKeeper Atomic Broadcast protocol)。

 

Zab协议有两种模式,它们分别是恢复模式(Recovery选主)和广播模式(Broadcast同步)。

 

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

 

为了保证事务的顺序一致性,zookeeper采用了递增的事务id号(zxid)来标识事务。所有的提议(proposal)都在被提出的时候加上了zxid。实现中zxid是一个64位的数字,它高32位是epoch用来标识leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch,标识当前属于那个leader的统治时期。低32位用于递增计数。

 

每个Server在工作过程中有4种状态:

 

LOOKING:当前Server不知道leader是谁,正在搜寻。

LEADING:当前Server即为选举出来的leader。

FOLLOWING:leader已经选举出来,当前Server与之同步。

OBSERVING:observer的行为在大多数情况下与follower完全一致,但是他们不参加选举和投票,而仅仅接受(observing)选举和投票的结果。

 

 

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

 

Zk的选举算法有两种:一种是基于basic paxos实现的,另外一种是基于fast paxos算法实现的。系统默认的选举算法为fast paxos。

 

先介绍basic paxos流程:

 

1.选举线程由当前Server发起选举的线程担任,其主要功能是对投票结果进行统计,并选出推荐的Server;

2.选举线程首先向所有Server发起一次询问(包括自己);

 

3.选举线程收到回复后,验证是否是自己发起的询问(验证zxid是否一致),然后获取对方的id(myid),并存储到当前询问对象列表中,最后获取对方提议的leader相关信息(id,zxid),并将这些信息存储到当次选举的投票记录表中;

 

4.收到所有Server回复以后,就计算出zxid最大的那个Server,并将这个Server相关信息设置成下一次要投票的Server;

 

5.线程将当前zxid最大的Server设置为当前Server要推荐的Leader,如果此时获胜的Server获得n/2 + 1的Server票数,设置当前推荐的leader为获胜的Server,将根据获胜的Server相关信息设置自己的状态,否则,继续这个过程,直到leader被选举出来。

 

通过流程分析我们可以得出:要使Leader获得多数Server的支持,则Server总数必须是奇数2n+1,且存活的Server的数目不得少于n+1.

 

每个Server启动后都会重复以上流程。在恢复模式下,如果是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息,zk会记录事务日志并定期进行快照,方便在恢复时进行状态恢复。

 

fast paxos流程是在选举过程中,某Server首先向所有Server提议自己要成为leader,当其它Server收到提议以后,解决epoch和zxid的冲突,并接受对方的提议,然后向对方发送接受提议完成的消息,重复这个流程,最后一定能选举出Leader。

 

 

zk选举:

 

1)、Leader选举实现细节

服务器有4种状态:

 

LOOKING:寻找Leader状态。当前Server不知道leader是谁,正在搜寻,因此需要进入Leader选举状态。

LEADING:当前Server即为选举出来的leader。

FOLLOWING:跟随者状态。表明当前服务器角色是Follower。

leader已经选举出来,当前Server与之同步。

OBSERVING:观察者状态。表明当前服务器角色是Observer。

observer的行为在大多数情况下与follower完全一致,但是他们不参加选举和投票,而仅仅接受(observing)选举和投票的结果。

 

2)、投票数据结构

 

每个投票中包含了两个最基本的信息,所推举服务器的SID和ZXID,投票(Vote)在Zookeeper中包含字段如下

id:被推举的Leader的SID。

zxid:被推举的Leader事务ID。

 

electionEpoch:逻辑时钟,用来判断多个投票是否在同一轮选举周期中,该值在服务端是一个自增序列,每次进入新一轮的投票后,都会对该值进行加1操作。

peerEpoch:被推举的Leader的epoch。

state:当前服务器的状态。

 

3)、QuorumCnxManager:网络I/O

 

每台服务器在启动的过程中,会启动一个QuorumPeerManager,负责各台服务器之间的底层Leader选举过程中的网络通信。

 

(1)消息队列。QuorumCnxManager内部维护了一系列的队列,用来保存接收到的、待发送的消息以及消息的发送器,除接收队列以外,其他队列都按照SID分组形成队列集合,如一个集群中除了自身还有3台机器,那么就会为这3台机器分别创建一个发送队列,互不干扰。

 

    · recvQueue:消息接收队列,用于存放那些从其他服务器接收到的消息。

    · queueSendMap:消息发送队列,用于保存那些待发送的消息,按照SID进行分组。

 

    · senderWorkerMap:发送器集合,每个SenderWorker消息发送器,都对应一台远程Zookeeper服务器,负责消息的发送,也按照SID进行分组。

    · lastMessageSent:最近发送过的消息,为每个SID保留最近发送过的一个消息。

 

(2)建立连接。

为了能够相互投票,Zookeeper集群中的所有机器都需要两两建立起网络连接。QuorumCnxManager在启动时会创建一个ServerSocket来监听Leader选举的通信端口(默认为3888)】。开启监听后,Zookeeper能够不断地接收到来自其他服务器的创建连接请求,在接收到其他服务器的TCP连接请求时,会进行处理。【为了避免两台机器之间重复地创建TCP连接,Zookeeper只允许SID大的服务器主动和其他机器建立连接,否则断开连接。】在接收到创建连接请求后,服务器通过对比自己和远程服务器的SID值来判断是否接收连接请求,如果当前服务器发现自己的SID更大,那么会断开当前连接,然后自己主动和远程服务器建立连接。一旦连接建立,就会根据远程服务器的SID来创建相应的消息发送器SendWorker和消息接收器RecvWorker,并启动。

 

(3)消息接收与发送。

消息接收:由消息接收器RecvWorker负责,由于Zookeeper为每个远程服务器都分配一个单独的RecvWorker,因此,每个RecvWorker只需要不断地从这个TCP连接中读取消息,并将其保存到recvQueue队列中。

 

消息发送:由于Zookeeper为每个远程服务器都分配一个单独的SendWorker,因此,每个SendWorker只需要不断地从对应的消息发送队列中获取出一个消息发送即可,同时将这个消息放入lastMessageSent中。在SendWorker中,一旦Zookeeper发现针对当前服务器的消息发送队列为空,那么此时需要从lastMessageSent中取出一个最近发送过的消息来进行再次发送,这是为了解决接收方在消息接收前或者接收到消息后服务器挂了,导致消息尚未被正确处理。同时,Zookeeper能够保证接收方在处理消息时,会对重复消息进行正确的处理。 

 

 

Leader选举

 

  2.1 Leader选举概述

  Leader选举是保证分布式数据一致性的关键所在。当Zookeeper集群中的一台服务器出现以下两种情况之一时,需要进入Leader选举。

 

  (1) 服务器初始化启动。

  (2) 服务器运行期间无法和Leader保持连接。

 

  下面就两种情况进行分析讲解。

 

  1. 服务器启动时期的Leader选举

 

  若进行Leader选举,则至少需要两台机器,这里选取3台机器组成的服务器集群为例。在集群初始化阶段,当有一台服务器Server1启动时,其单独无法进行和完成Leader选举,当第二台服务器Server2启动时,此时两台机器可以相互通信,每台机器都试图找到Leader,于是进入Leader选举过程。选举过程如下

 

  (1) 每个Server发出一个投票。由于是初始情况,Server1和Server2都会将自己作为Leader服务器来进行投票,每次投票会包含所推举的服务器的myid和ZXID,使用(myid, ZXID)来表示,此时Server1的投票为(1, 0),Server2的投票为(2, 0),然后各自将这个投票发给集群中其他机器。

 

  (2) 接受来自各个服务器的投票。集群的每个服务器收到投票后,首先判断该投票的有效性,如检查是否是本轮投票、是否来自LOOKING状态的服务器。

 

  (3) 处理投票。针对每一个投票,服务器都需要将别人的投票和自己的投票进行PK,PK规则如下

 

    · 优先检查ZXID。ZXID比较大的服务器优先作为Leader。

    · 如果ZXID相同,那么就比较myid。myid较大的服务器作为Leader服务器。

 

  对于Server1而言,它的投票是(1, 0),接收Server2的投票为(2, 0),首先会比较两者的ZXID,均为0,再比较myid,此时Server2的myid最大,于是更新自己的投票为(2, 0),然后重新投票,对于Server2而言,其无须更新自己的投票,只是再次向集群中所有机器发出上一次投票信息即可。

 

  (4) 统计投票。每次投票后,服务器都会统计投票信息,判断是否已经有过半机器接受到相同的投票信息,对于Server1、Server2而言,都统计出集群中已经有两台机器接受了(2, 0)的投票信息,此时便认为已经选出了Leader。

 

  (5) 改变服务器状态。一旦确定了Leader,每个服务器就会更新自己的状态,如果是Follower,那么就变更为FOLLOWING,如果是Leader,就变更为LEADING。

 

  2. 服务器运行时期的Leader选举

 

  在Zookeeper运行期间,Leader与非Leader服务器各司其职,即便当有非Leader服务器宕机或新加入,此时也不会影响Leader,但是一旦Leader服务器挂了,那么整个集群将暂停对外服务,进入新一轮Leader选举,其过程和启动时期的Leader选举过程基本一致。假设正在运行的有Server1、Server2、Server3三台服务器,当前Leader是Server2,若某一时刻Leader挂了,此时便开始Leader选举。选举过程如下

 

  (1) 变更状态。Leader挂后,余下的非Observer服务器都会讲自己的服务器状态变更为LOOKING,然后开始进入Leader选举过程。

 

  (2) 每个Server会发出一个投票。在运行期间,每个服务器上的ZXID可能不同,此时假定Server1的ZXID为123,Server3的ZXID为122;在第一轮投票中,Server1和Server3都会投自己,产生投票(1, 123),(3, 122),然后各自将投票发送给集群中所有机器。

 

  (3) 接收来自各个服务器的投票。与启动时过程相同。

  (4) 处理投票。与启动时过程相同,此时,Server1将会成为Leader。

  (5) 统计投票。与启动时过程相同。

  (6) 改变服务器的状态。与启动时过程相同。

 

 

  2.2 Leader选举算法分析

 

  在3.4.0后的Zookeeper的版本只保留了TCP版本的FastLeaderElection选举算法。当一台机器进入Leader选举时,当前集群可能会处于以下两种状态

 

    · 集群中已经存在Leader。

    · 集群中不存在Leader。

 

  对于集群中已经存在Leader而言,此种情况一般都是某台机器启动得较晚,在其启动之前,集群已经在正常工作,对这种情况,该机器试图去选举Leader时,会被告知当前服务器的Leader信息,对于该机器而言,仅仅需要和Leader机器建立起连接,并进行状态同步即可。而在集群中不存在Leader情况下则会相对复杂,其步骤如下

 

  (1)第一次投票。无论哪种导致进行Leader选举,集群的所有机器都处于试图选举出一个Leader的状态,即LOOKING状态,LOOKING机器会向所有其他机器发送消息,该消息称为投票。投票中包含了SID(服务器的唯一标识)和ZXID(事务ID),(SID, ZXID)形式来标识一次投票信息。假定Zookeeper由5台机器组成,SID分别为1、2、3、4、5,ZXID分别为9、9、9、8、8,并且此时SID为2的机器是Leader机器,某一时刻,1、2所在机器出现故障,因此集群开始进行Leader选举。在第一次投票时,每台机器都会将自己作为投票对象,于是SID为3、4、5的机器投票情况分别为(3, 9),(4, 8), (5, 8)。

 

  (2)变更投票。每台机器发出投票后,也会收到其他机器的投票,每台机器会根据一定规则来处理收到的其他机器的投票,并以此来决定是否需要变更自己的投票,这个规则也是整个Leader选举算法的核心所在,其中术语描述如下

 

    · vote_sid:接收到的投票中所推举Leader服务器的SID。

    · vote_zxid:接收到的投票中所推举Leader服务器的ZXID。

    · self_sid:当前服务器自己的SID。

    · self_zxid:当前服务器自己的ZXID。

 

  每次对收到的投票的处理,都是对(vote_sid, vote_zxid)和(self_sid, self_zxid)对比的过程。

 

    规则一:如果vote_zxid大于self_zxid,就认可当前收到的投票,并再次将该投票发送出去。

    规则二:如果vote_zxid小于self_zxid,那么坚持自己的投票,不做任何变更。

    规则三:如果vote_zxid等于self_zxid,那么就对比两者的SID,如果vote_sid大于self_sid,那么就认可当前收到的投票,并再次将该投票发送出去。

    规则四:如果vote_zxid等于self_zxid,并且vote_sid小于self_sid,那么坚持自己的投票,不做任何变更。

 

  结合上面规则,给出下面的集群变更过程。

 

 

  (3)确定Leader。经过第二轮投票后,集群中的每台机器都会再次接收到其他机器的投票,然后开始统计投票,如果一台机器收到了超过半数的相同投票,那么这个投票对应的SID机器即为Leader。此时Server3将成为Leader。

 

  由上面规则可知,通常那台服务器上的数据越新(ZXID会越大),其成为Leader的可能性越大,也就越能够保证数据的恢复。如果ZXID相同,则SID越大机会越大。

 

  • 大小: 17 KB
  • 大小: 26.5 KB
分享到:
评论

相关推荐

    自动动手写zookeeper选举算法与心跳同步

    本文将深入探讨Zookeeper中的选举算法和心跳同步机制,这两个概念对于理解Zookeeper如何保证集群的一致性和高可用性至关重要。 首先,让我们从选举算法开始。在Zookeeper中,最常用的选举算法是Fast Paxos,它是在...

    zookeeper选举机制图

    zookeeper选举机制图,内讲述了zookeeper是如何选举出leader、fllower的

    C# 关于zookeeper主从选举的源码

    - ZAB(Zookeeper Atomic Broadcast)协议是Zookeeper的原子广播协议,它包含了选举算法。基本思路是通过比较每个节点的选举优先级(通常是服务器ID)和提议的事务ID来确定领导者。 - 当多数节点同意一个节点为...

    用java实现HS和LCR选举算法

    在分布式系统中,选举算法是确保一致性、容错性和稳定性的重要工具。HS(Hunt-Szymanski)算法和LCR(Lamport's Cluster Membership)算法是两种经典的领导者选举算法,常用于分布式环境中的主节点选择或者一致性...

    zookeeperMaster选举以及数据同步代码

    Zookeeper提供了原子性的`Leader Election`算法,确保在节点之间选举出一个领导者。这个过程通常包括节点注册、心跳检测、投票选举等步骤。当一个节点发现当前没有领导者时,就会发起选举,每个节点根据其ID或状态...

    zookeeper管理机制

    #### 二、Zookeeper选举算法分析 Zookeeper支持两种选举算法:基于Basic Paxos的实现和基于Fast Paxos的实现。 - **Basic Paxos**:是一种基本的分布式共识算法,适用于Zookeeper的选举场景。该算法保证了系统的...

    zookeeper学习视频.rar

    6. **Zookeeper选举算法**:了解Zookeeper如何通过ZAB(Zookeeper Atomic Broadcast)协议实现主节点选举,理解Leader、Follower和Observer的角色与职责。 7. **分布式应用中的Zookeeper**:在分布式锁、配置管理、...

    18340013_陈琮昊_分布式系统作业51

    1. **Zookeeper选举算法** Zookeeper采用了基于Zxid(事务ID)的选举算法。在Zookeeper集群中,每个服务器都有一个myid标识符和ZXID,用来记录该服务器处理过的事务。选举流程分为两种情况: - **服务器初始化...

    zookeeper代码例子

    10. **ZooKeeper选举算法**: - 通常采用Fast Leader Election算法,确保在分布式环境中快速选举出领导者。 通过深入学习和实践这些示例代码,你可以掌握ZooKeeper的基本操作以及如何在实际项目中应用这些概念。...

    分布式选举算法

    为了克服这些限制,实际的分布式系统可能会结合其他选举算法,如Paxos、Raft或Zookeeper的选举机制,以提高可靠性和效率。学习和理解Bully算法是深入研究分布式系统和选举算法的良好起点,对于希望在IT领域从事...

    fast paxos算法与zookeeper leader选举源代码分析.doc

    fast paxos算法与zookeeper leader选举源代码分析.doc

    zookeeper基于paxos算法的资料。

    在Zookeeper中,Paxos算法被用来选举 Leader 和维护集群的状态一致性。Paxos算法通常包括提议者(Proposer)、接受者(Acceptor)和学习者(Learner)三个角色。在Zookeeper中,这些角色分别对应于客户端、服务器...

    理解zookeeper选举机制

    Zookeeper提供了三种选举算法:LeaderElection、AuthFastLeaderElection和FastLeaderElection。其中,FastLeaderElection是默认的算法,我们主要讨论这个。 选举机制中的关键概念包括: 1. **服务器ID**:每个...

    Zookeeper源码分析

    本文将深入剖析Zookeeper的工作原理,以及其内部实现的FastLeader选举算法和Paxos算法。 首先,我们来看Zookeeper的工作原理概述。Zookeeper采用一种基于ZAB协议的分布式一致性模型,该协议是为Zookeeper定制的,...

    zookeeper-3.8.0安装包下载

    通过选举算法确定一个 Leader 节点,其他节点作为 Follower 或 Observer。Leader 负责处理所有客户端的写请求,并向其他节点广播更新,确保数据的一致性。 对于学习 Zookeeper 的学生或部署的工作人员,了解以下...

    zookeeper3.36

    4. 领导者选举:如Kafka、HBase等分布式系统,通过Zookeeper选举领导者。 六、Zookeeper 3.3.6的改进与优化 Zookeeper 3.3.6版本主要提升了性能和稳定性,修复了一些已知的问题,增强了对大规模部署的支持。同时,...

    ZooKeeper-分布式过程协同技术详解 和从Paxos到Zookeeper

    《ZooKeeper:分布式过程协同技术详解》与《从Paxos到Zookeeper:分布式一致性原理与实践》这两本书深入探讨了分布式系统中的关键组件ZooKeeper及其背后的一致性算法Paxos。ZooKeeper是由Apache软件基金会开发的一个...

    zookeeper-3.4.14.zip

    4. **选举算法**:在 Ensemble 模式下,ZooKeeper 使用选举算法来确定集群中的领导者,确保数据的一致性。 5. **原子操作**:所有对 ZooKeeper 的操作都是原子的,即要么全部完成,要么全部不完成,保证了数据操作...

    zookeeper.7z

    - **Zookeeper 的选举算法**:Zookeeper 使用的是 Fast Leader Election 算法,它能够在短时间内选举出领导者,保证系统的快速恢复。 5. **Zookeeper 的运维与调优** - **监控与日志**:监控 Zookeeper 的运行...

Global site tag (gtag.js) - Google Analytics