Zookeeper的架构设计及原理分析

Zookeeper的架构设计及原理分析

架构设计

Zookeeper作为一个分布式协调组件,很多应用系统都会依赖Zookeeper来实现相关业务的处理。

在分布式架构中任何节点都不能以单点状态存在,所以Zookeeper首先需要解决的是单点故障问题,而常见的解决方案就是做主从集群。

这个集群需要满足那些功能?

1、集群中要有主节点和从节点(也就是集群要有角色)。

2、集群要能做到数据同步,当主节点出现故障时,从节点能够顶替主节点继续工作,但是继续工作的前提是数据必须要主节点保持一致。

3、主节点挂了以后,从节点如何接替成为主节点?是人工干预?还是自动选举。

Zookeeper中,集群角色分为三种,分别是Leader、Follower、Observer。

Leader角色

Leader服务器是整个zookeeper集群的核心,主要的工作任务有两项

1、事物请求的唯一调度和处理者,保证集群事物处理的顺序性

2、集群内部各服务器的调度者

Follower角色

Follower角色的主要职责是

1、处理客户端非事物请求、转发事物请求给leader服务器

2、参与事物请求Proposal的投票(需要半数以上服务器通过才能通知leader commit数据;Leader发起的提案,要求Follower投票)

3、参与Leader选举的投票

Observer角色

Observer是zookeeper3.3开始引入的一个全新的服务器角色,从字面来理解,该角色充当了观察者的角色。

观察zookeeper集群中的最新状态变化并将这些状态变化同步到observer服务器上。

Observer的工作原理与follower角色基本一致,而它和follower角色唯一的不同在于observer不参与任何形式的投票,包括事物请求Proposal的投票和leader选举的投票。简单来说,observer服务器只提供非事物请求服务,通常在于不影响集群事物处理能力的前提下提升集群非事物处理的能力。

节点之间的数据同步

如果要满足这样的一个高性能集群,最直观的想法应该是,每个节点都能接收到请求,并且每个节点的数据都必须要保持一致。

要实现各个节点的数据一致性,就势必要一个leader节点负责协调和数据同步操作。如果在这样一个集群中没有leader节点,每个节点都可以接收所有请求,那么这个集群的数据同步的复杂度是非常大。

image-20210828193452905

如图所示,当客户端请求过来时,需要满足,事务型数据和非事务型数据的分开处理方式,就是leader节点可以处理事务和非事务型数据。而follower节点只能处理非事务型数据。

原因是,对于数据变更的操作,应该由一个节点来维护,使得集群数据处理的简化,同时数据需要能够通过leader进行分发使得数据在集群中各个节点的一致性。

leader节点如何和其他节点保证数据一致性,并且要求是强一致的。在分布式系统中,每一个机器节点虽然都能够明确知道自己进行的事务操作过程是成功和失败,但是却无法直接获取其他分布式节点的操作结果。所以当一个事务操作涉及到跨节点的时候,就需要用到分布式事务,分布式事务的数据一致性协议有2PC协议和3PC协议。

2PC

2PC(Two Phase Commitment Protocol)当一个事务操作需要跨越多个分布式节点的时候,为了保持事务处理的ACID特性,就需要引入一个“协调者”(TM)来统一调度所有分布式节点的执行逻辑,这些被调度的分布式节点被称为AP。TM负责调度AP的行为,并最终决定这些AP是否要把事务真正进行提交;因为整个事务是分为两个阶段提交,所以叫2pc。

image-20210828193743335

阶段一:提交事务请求(投票)

1、事务询问

协调者向所有的参与者发送事务内容,询问是否可以执行事务提交操作,并开始等待各参与者的响应

2、执行事务

各个参与者节点执行事务操作,并将Undo和Redo信息记录到事务日志中,尽量把提交过程中所有消耗时间的操作和准备都提前完成确保后面100%成功提交事务

3.各个参与者向协调者反馈事务询问的响应

如果各个参与者成功执行了事务操作,那么就反馈给参与者yes的响应,表示事务可以执行;如果参与者没有成功执行事务,就反馈给协调者no的响应,表示事务不可以执行,上面这个阶段有点类似协调者组织各个参与者对一次事务操作的投票表态过程,因此2pc协议的第一个阶段称为“投票阶段”,即各参与者投票表名是否需要继续执行接下去的事务提交操作。

阶段二:执行事务提交

在这个阶段,协调者会根据各参与者的反馈情况来决定最终是否可以进行事务提交操作,正常情况下包含两种可能:执行事务、中断事务

在Zookeeper中,采用少数服从多数的方式来实现数据同步,也就是不需要所有节点都在第一阶段给出明确的事务提交成功的回复,只需要大于半数节点都提交成功,那么Zookeeper认为该数据已经同步完成。

Zookeeper的集群组成

image-20210828194152339

如图所示,通常zookeeper是由2n+1台server组成,每个server都知道彼此的存在。每个server都维护的内存状态镜像以及持久化存储的事务日志和快照。

对于2n+1台server,只要有n+1台(大多数)server可用,整个系统保持可用。一个zookeeper集群如果要对外提供可用的服务,那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信,

基于这个特性,如果想搭建一个能够允许F台机器down掉的集群,那么就要部署2*F+1台服务器构成的zookeeper集群。因此3台机器构成的zookeeper集群,能够在挂掉一台机器后依然正常工作。

一个5台机器集群的服务,能够对2台机器怪调的情况下进行容灾。如果一台由6台服务构成的集群,同样只能挂掉2台机器。因此,5台和6台在容灾能力上并没有明显优势,反而增加了网络通信负担。

系统启动时,集群中的server会选举出一台server为Leader,其它的就作为follower(这里先不考虑observer角色)。

之所以要满足这样一个等式,是因为一个节点要成为集群中的leader,需要有超过及群众过半数的节点支持,这个涉及到leader选举算法,同时也涉及到事务请求的提交投票。

Zookeeper中的一致性

zookeeper并不是强一致性服务,它是一个最终一致性模型,具体情况如图所示。

image-20210828195150906

ClientA/B/C假设只串行执行,clientA更新zookeeper上的一个值x。ClientB和clientC分别读取集群的不同副本,返回的x的值是不一样的,clientC的读取操作是发生在clientB之后,但是却读到了过期的值。

很明显,这是一种弱一致模型,如果用它来实现锁机制是有问题的。

顺序一致性模型

顺序一致性提供了更强的一致性保证,如图所示,从时间轴来看,B0发生在A0之前,读取的值是0,B2发生在A0之后,读取到的x的值为1,而读操作B1/C0/C1和写操作A0在时间轴上有重叠,因此他们可能读到旧的值为0,也可能读到新的值1。

但是在强顺序一致性模型中,如果B1得到的x的值为1,那么C1看到的值也一定是1。

image-20210828195439756

需要注意的是:由于网络的延迟以及系统本身执行请求的不确定性,会导致请求发起的早的客户端不一定会在服务端执行得早,最终以服务端执行的结果为准。

简单来说:顺序一致性是针对单个操作,单个数据对象。属于CAP中C这个范畴,一个数据被更新后,能够立马被后续的读操作读到。

但是zookeeper的顺序一致性实现是缩水版的,在官网上,可以看到对于一致性这块做了解释。

zookeeper不保证在每个实例中,两个不同的客户端具有相同的zookeeper数据视图,由于网络延迟等因素,一个客户端可能会在另外一个客户端收到更改通知之前执行更新,考虑到2个客户端A和B的场景,如果A把znode /a 的值从0设置为1,然后告诉客户端B读取/a,则客户端B可能会读取到旧的值0,具体取决于他连接到那个服务器,如果客户端A和B要读取必须要读取到相同的值,那么client B在读取操作之前执行sync方法,zooKeeper.sync()

除此之外,zookeeper基于zxid以及阻塞队列的方式来实现请求的顺序一致性。如果一个client连接到一个最新的follower上,那么它read读取到了最新的数据,然后client由于网络原因重新连接到zookeeper节点,而这个时候连接到一个还没有完成数据同步的follower节点,那么这一次读到的数据不久是旧的数据吗?

实际上zookeeper处理了这种情况,client会记录自己已经读取到的最大的zxid,如果client重连到server发现client的zxid比自己大,连接会失败。

Zookeeper数据同步流程

在zookeeper中,客户端会随机连接到zookeeper集群中的一个节点,如果是读请求,就直接从当前节点中读取数据,如果是写请求,那么请求会被转发给leader提交事务,然后leader会广播事务,只要有超过半数节点写入成功,那么写请求就会被提交(类2PC事务)。

所有事务请求必须由一个全局唯一的服务器来协调处理,这个服务器就是Leader服务器,其他的服务器就是follower。leader服务器把客户端的请求转化成一个事务Proposal(提议),并把这个Proposal分发给集群中的所有Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈,一旦超过半数的Follower服务器进行了正确的反馈,那么Leader就会再次向所有的Follower服务器发送Commit消息,要求各个follower节点对前面的一个Proposal进行提交。

那么问题来了

1、集群中的leader节点如何选举出来?

2、leader节点崩溃以后,整个集群无法处理写请求,如何快速从其他节点里面选举出新的leader呢?

3、leader节点和各个follower节点的数据一致性如何保证

ZAB协议

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

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

ZAB协议包含两种基本模式,分别是:

1.崩溃恢复

2.原子广播

当整个集群在启动时,或者当leader节点出现网络中断、崩溃等情况时,ZAB协议就会进入恢复模式并选举产生新的Leader,当leader服务器选举出来后,并且集群中有过半的机器和该leader节点完成数据同步后(同步指的是数据同步,用来保证集群中过半的机器能够和leader服务器的数据状态保持一致),ZAB协议就会退出恢复模式。

当集群中已经有过半的Follower节点完成了和Leader状态同步以后,那么整个集群就进入了消息广播模式。这个时候,在Leader节点正常工作时,启动一台新的服务器加入到集群,那这个服务器会直接进入数据恢复模式,和leader节点进行数据同步。

同步完成后即可正常对外提供非事务请求的处理。

需要注意的是:leader节点可以处理事务请求和非事务请求,follower节点只能处理非事务请求,如果follower节点接收到非事务请求,会把这个请求转发给Leader服务器。

消息广播的实现原理

如图所示,消息广播的过程实际上是一个简化版本的二阶段提交过程

1、leader接收到消息请求后,将消息赋予一个全局唯一的64位自增id,叫:zxid,通过zxid的大小比较既可以实现全局有序这个特征

2、leader为每个follower准备了一个FIFO队列(通过TCP协议来实现,以实现了全局有序这一个特点)将带有zxid的消息作为一个提案(proposal)分发给所有的follower

3、当follower接收到proposal,先把proposal写到磁盘,写入成功以后再向leader回复一个ack

4、当leader接收到合法数量(超过半数节点)的ACK后,leader就会向这些follower发送commit命令,同时会在本地执行该消息

5、当follower收到消息的commit命令以后,会提交该消息

image-20210828202458890

和完整的2pc事务不一样的地方在于,zab协议不能终止事务,follower节点要么ACK给eader,要么抛弃leader,只需要保证过半数的节点响应这个消息并提交了即可,虽然在某一个时刻follower节点和eader节点的状态会不一致,但是也是这个特性提升了集群的整体性能。当然这种数据不一致的问题,zab协议提供了一种恢复模式来进行数据恢复。

这里需要注意的是:

leader的投票过程,不需要Observer的ack,也就是Observer不需要参与投票过程,但是Observer必须要同步Leader的数据从而在处理请求的时候保证数据的一致性。

崩溃恢复的实现原理

前面我们已经清楚了ZAB协议中的消息广播过程,ZAB协议的这个基于原子广播协议的消息广播过程,在正常情况下是没有任何问题的,但是一旦Leader节点崩溃,或者由于网络问题导致Leader服务器失去了过半的Follower节点的联系(leader失去与过半follower节点联系,可能是leader节点和follower节点之间产生了网络分区,那么此时的leader不再是合法的leader了),那么就会进入到崩溃恢复模式。

崩溃恢复状态下zab协议需要做两件事

1、选举出新的leader

2、数据同步

前面在讲解消息广播时,知道ZAB协议的消息广播机制是简化版本的2PC协议,这种协议只需要集群中过半的节点响应提交即可。但是它无法处理Leader服务器崩溃带来的数据不一致问题。因此在ZAB协议中添加了一个”崩溃恢复模式”来解决这个问题。

那么ZAB协议中的崩溃恢复需要保证,如果一个事务Proposal在一台机器上被处理成功,那么这个事务应该在所有机器上都被处理成功,哪怕是出现故障。

为了达到这个目的,先来设想一下,在zookeeper中会有哪些场景导致数据不一致性,以及针对这个场景,zab协议中的崩溃恢复应该怎么处理。

已经被处理的消息不能丢弃

当leader收到合法数量follower的ACKs后,就向各个follower广播COMMIT命令,同时也会在本地执行COMMIT并向连接的客户端返回「成功」,但是如果在各个follower在收到COMMIT命令前leader就挂了,导致剩下的服务器并没有执行都这条消息。

图中的C2就是一个典型的例子,在集群正常运行过程的某一个时刻,Server1是leader服务器,先后广播了消息P1、P2、C1、P3和C2。

其中当leader服务器把消息C2(Commit事务proposal2)发出后就立即崩溃退出了,那么针对这种情况,ZAB协议就需要确保事务Proposal 2 最终能够在所有的服务器上都能被提交成功,否则将会出现不一致。

image-20210828204132582

被丢弃的消息不能再次出现

如图所示,当leader接收到消息请求生成proposal后就挂了,其他follower并没有收到此proposal。

因此经过恢复模式重新选了leader后,这条消息是被跳过的。此时,之前挂了的leader重新启动并注册成了follower,他保留了被跳过消息的proposal状态,与整个系统的状态是不一致的,需要将其删除。

image-20210828204337011

ZAB协议需要满足上面两种情况,就必须要设计一个leader选举算法:能够确保已经被leader提交的事务Proposal能够提交、同时丢弃已经被跳过的事务Proposal。

针对这个要求

1、如果leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器最高编号(ZXID最大)的事务Proposal,那么就可以保证这个新选举出来的Leader一定具有已经提交的提案。

2、因为所有提案被COMMIT之前必须有超过半数的followerACK,即必须有超过半数节点的服务器的事务日志上有该提案的proposal,因此,只要有合法数量的节点正常工作,就必然有一个节点保存了所有被COMMIT消息的proposal状态。

3、另外一个,zxid是64位,高32位是epoch编号,每经过一次Leader选举产生一个新的leader,新的leader会将epoch号+1,低32位是消息计数器,每接收到一条消息这个值+1。

4、新leader选举后这个值重置为0,这样设计的好处在于老的leader挂了以后重启,它不会被选举为leader,因此此时它的zxid肯定小于当前新的leader。

5、当老的leader作为follower接入新的leader后,新的leader会让它将所有的拥有旧的epoch号的未被COMMIT的proposal清除。

关于ZXID

ZXID是Zookeeper中的数据对应的事务ID。

为了保证事务的顺序一致性,zookeeper采用了递增的事务id号(zxid)来标识事务,所有的提议(proposal)都在被提出的时候加上了zxid,通过stat命令查看节点的信息如下。

1
2
3
4
5
6
7
8
9
10
11
12
[zk:1ocalhost:2181(CONNECTED) 3] stat /node 
cZxid = 0x5c67
ctime = Thu Aug 19 21:48:16 CST 2021
mZxid = 0x5c67
mtime = Thu Aug 19 21:48:16 CST 2021
pZxid = 0x5c67
cversion = 0
dataVersion = O
aclVersion = 0
ephemeralowner = 0x0
dataLength = 3
numChildren = 0

实现中zxid是一个64位的数字,它高32位是epoch(ZAB协议通过epoch编号来区分Leader周期变化的策略)用来标识leader关系是否改变,每次一个leader被选出来,它都会有一个新的epoch(原来的epoch+1),标识当前属于那个leader的统治时期。低32位用于递增计数。

比如0x5c67,实际上是:500000c67,前面的5表示epoch,后面的c67是16进制的递增编号。

image-20210828204920161

epoch:可以理解为当前集群所处的年代或者周期,每个leader就像皇帝,都有自己的年号,所以每次改朝换代,leader变更之后,都会在前一个年代的基础上加1,这样就算旧的leader崩溃恢复之后,也没有人听他的了,因为follower只听从当前年代的leader的命令。

zxid达到最大值后会触发集群重新选举,然后zxid会变为0。日志中会看到如下信息:

1
INFO [ProcessThread(sid:31814 cport:-l)::PrepRequestprocessor@137]-zxid lower 32 bits have rolled over, forcing re-election, and therefore new epoch start

Zookeeper的事务日志

Zookeeper的数据是持久化在磁盘上的,默认的目录是在/tmp/zookeeper下,这个目录中会存放事务日志和快照日志。

该路径可以通过zoo.cfg文件来修改,

1
2
3
4
#内存数据库快照存放地址
dataDir=/data/zookeeper-3.4.6/data
#事务日志存储
datalogDir=/data/zookeeper-3.4.6/data/1og

在该目录下可以看到有以下文件内容,在Zab协议中我们知道每当有接收到客户端的事务请求后Leader与Follower都会将把该事务日志存入磁盘日志文件中,该日志文件就是这里所说的事务日志。

image-20210828213229421

其中文件的命名是log.zxid,其中zxid表示当前日志文件中开始记录的第一条数据的zxid。

这些内容我们是可以通过Zookeeper自带的工具来查看的,使用命令如下

查看事务日志文件的命令

1
2
java -cp :/data/program/apache-zookeeper-3.6.1-bin/lib/slf4j-api-
1.7.25.jar:/data/program/apache-zookeeper-3.6.1-bin/1ib/zookeeper-jute- 3.6.1.jar:/data/program/apache-zookeeper-3.6.1-bin/1ib/zookeeper-3.6.1.jar org.apache.zookeeper.server. LogFormatter 1og.1

查看快照文件的命令

1
2
3
java -cp :/data/program/apache-zookeeper-3.6.l-bin/1ib/s1f4j-api-
1.7.25.jar:/data/program/apache-zookeeper-3.6.l-bin/1ib/zookeeper-jute- 3.6.1.jar:/data/program/apache-zookeeper-3.6.1-bin/1ib/zookeeper-
3.6.1.jar:/data/program/apache-zookeeper-3.6.1-bin/lib/snappy-java-1.1.7.jar org.apache.zookeeper.server. SnapshotFormatter snapshot.0

Leader选举原理分析

接下来分析leader选举的整个实现过程。

leader选举存在与两个阶段中,一个是服务器启动时的leader选举,另一个是运行过程中leader节点宕机导致的leader选举;

在开始分析选举的原理之前,先了解几个重要的参数

  • 服务器ID(myid)

比如有三台服务器,编号分别是1,2,3。

编号越大在选择算法中的权重越大。

  • zxid事务id

值越大说明数据越新,在选举算法中的权重也越大

  • 逻辑时钟(epoch-logicalclock)

或者叫投票的次数,同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加,然后与接收到的其它服务器返回的投票信息中的数值相比,根据不同的值做出不同的判断

  • 选举状态

LOOKING,竞选状态。

FOLLOWING,随从状态,同步leader状态,参与投票。

OBSERVING,观察状态,同步leader状态,不参与投票。

LEADING,领导者状态。

服务器启动时的leader选举

每个节点启动的时候状态都是LOOKING,处于观望状态,接下来就开始进行选主流程

若进行Leader选举,则至少需要两台机器,这里选取3台机器组成的服务器集群为例。

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

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

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

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

i、优先比较epoch

ii、其次检查ZXID。ZXID比较大的服务器优先作为Leader

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

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

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

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

运行过程中的leader选举

当集群中的leader服务器出现宕机或者不可用的情况时,那么整个集群将无法对外提供服务,而是进入新一轮的Leader选举,服务器运行期间的Leader选举和启动时期的Leader选举基本过程是一致的。

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

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

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

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

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

可能出现的问题

脑裂和假死

脑裂

官方定义:当一个集群的不同部分在同一时间都认为自己是活动的时候,我们就可以将这个现象称为脑裂症状。通俗的说,就是比如当你的 cluster 里面有两个节点,它们都知道在这个 cluster 里需要选举出一个 master。那么当它们两之间的通信完全没有问题的时候,就会达成共识,选出其中一个作为 master,但是如果它们之间的通信出了问题,那么两个节点都会觉得现在没有 master,所以每个都把自己选举成 master,于是 cluster 里面就会有两个 master。

对于Zookeeper来说有一个很重要的问题,就是到底是根据一个什么样的情况来判断一个节点死亡down掉了。 在分布式系统中这些都是有监控者来判断的,但是监控者也很难判定其他的节点的状态,唯一一个可靠的途径就是心跳,Zookeeper也是使用心跳来判断客户端是否仍然活着,但是使用心跳机制来判断节点的存活状态也带来了假死问题。

假死

ZooKeeper每个节点都尝试注册一个象征master的临时节点,其他没有注册成功的则成为slaver,并且通过watch机制监控着master所创建的临时节点,Zookeeper通过内部心跳机制来确定master的状态,一旦master出现意外Zookeeper能很快获悉并且通知其他的slaver,其他slaver在之后作出相关反应。这样就完成了一个切换。

这种模式也是比较通用的模式,基本大部分都是这样实现的,但是这里面有个很严重的问题,如果注意不到会导致短暂的时间内系统出现脑裂,因为心跳出现超时可能是master挂了,但是也可能是master,zookeeper之间网络出现了问题,也同样可能导致。这种情况就是假死,master并未死掉,但是与ZooKeeper之间的网络出现问题导致Zookeeper认为其挂掉了然后通知其他节点进行切换,这样slaver中就有一个成为了master,但是原本的master并未死掉,这时候client也获得master切换的消息,但是仍然会有一些延时,zookeeper需要通讯需要一个一个通知,这时候整个系统就很混乱可能有一部分client已经通知到了连接到新的master上去了,有的client仍然连接在老的master上如果同时有两个client需要对master的同一个数据更新并且刚好这两个client此刻分别连接在新老的master上,就会出现很严重问题。

总结

假死:由于心跳超时(网络原因导致的)认为master死了,但其实master还存活着。

脑裂:由于假死会发起新的master选举,选举出一个新的master,但旧的master网络又通了,导致出现了两个master ,有的客户端连接到老的master 有的客户端链接到新的master。

Zookeeper的解决方案

要解决Split-Brain的问题,一般有3种方式:

  • Quorums(法定人数) :比如3个节点的集群,Quorums = 2, 也就是说集群可以容忍1个节点失效,这时候还能选举出1个lead,集群还可用。比如4个节点的集群,它的Quorums = 3,Quorums要超过3,相当于集群的容忍度还是1,如果2个节点失效,那么整个集群还是无效的

  • Redundant communications:冗余通信的方式,集群中采用多种通信方式,防止一种通信方式失效导致集群中的节点无法通信。

  • Fencing,共享资源的方式:比如能看到共享资源就表示在集群中,能够获得共享资源的锁的就是Leader,看不到共享资源的,就不在集群中。

ZooKeeper默认采用了Quorums这种方式,即只有集群中超过半数节点投票才能选举出Leader。这样的方式可以确保leader的唯一性,要么选出唯一的一个leader,要么选举失败。

在ZooKeeper中Quorums有2个作用:

集群中最少的节点数用来选举Leader保证集群可用:通知客户端数据已经安全保存前集群中最少数量的节点数已经保存了该数据。一旦这些节点保存了该数据,客户端将被通知已经安全保存了,可以继续其他任务。而集群中剩余的节点将会最终也保存了该数据。

假设某个leader假死,其余的followers选举出了一个新的leader。这时,旧的leader复活并且仍然认为自己是leader,这个时候它向其他followers发出写请求也是会被拒绝的。因为每当新leader产生时,会生成一个epoch,这个epoch是递增的,followers如果确认了新的leader存在,知道其epoch,就会拒绝epoch小于现任leader epoch的所有请求。那有没有follower不知道新的leader存在呢,有可能,但肯定不是大多数,否则新leader无法产生。Zookeeper的写也遵循quorum机制,因此,得不到大多数支持的写是无效的,旧leader即使各种认为自己是leader,依然没有什么作用。

总结

总结一下就是,通过Quorums机制来防止脑裂和假死,当leader挂掉之后,可以重新选举出新的leader节点使整个集群达成一致;当出现假死现象时,通过epoch大小来拒绝旧的leader发起的请求,在前面也已经讲到过,这个时候,重新恢复通信的老的leader节点会进入恢复模式,与新的leader节点做数据同步。

打赏

请我喝杯咖啡吧~

支付宝
微信