- 丢弃只在Leader服务器上被提出(未提交)的事务。
假设初始的 Leader 服务器 Server1 在提出了⼀个事务Proposal3 之后就崩溃退出 了,从⽽导致集群中的其他服务器都没有收到这个事务Proposal3。于是,当 Server1 恢复过来再次加 ⼊到集群中的时候,ZAB 协议需要确保丢弃Proposal3这个事务。
综上所述,ZAB的选举出来的Leader必须满足以下条件:
能够确保提交已经被 Leader 提交的事务 Proposal,同时丢弃已经被跳过的事务 Proposal。即:
1.新选举出来的 Leader 不能包含未提交的 Proposal。
2.新选举的 Leader 节点中含有最大的 zxid 。
ZAB如何数据同步
所有正常运行的服务器要么成为Leader,要么成为Follower并和Leader保持同步。
1.完成Leader选举(新的 Leader 具有最高的zxid)之后,在正式开始⼯作(接收客户端请求)之前,Leader服务器会⾸先确认事务⽇志中的所有Proposal是否都已经被集群中过半的机器提交了,即 是否完成数据同步 。
2.Leader服务器需要确保所有的Follower服务器能够接收到每⼀条事务Proposal,并且能够正确地将所有已经提交了的事务Proposal应⽤到内存数据中。等到 Follower服务器将所有其尚未同步的事务 Proposal 都从 Leader 服务器上同步过来并成功应⽤到本地数据库中后,Leader服务器就会将该Follower服务器加⼊到真正的可⽤Follower列表中,并开始之后的其他流程。
ZAB运行时状态#
ZAB协议设计中,每个进程都有可能处于如下三种状态之一:
-
LOOKING:Leader选举状态,正在寻找Leader
-
FOLLOWING:当前节点是Follower。与Leader服务器保持同步状态
-
LEADING:当前节点是Leader,作为主进程领导状态。
ZAB状态的切换
启动时的状态转换
1.所有进程的初始状态都是LOOKING状态,此时不存在Leader。
2.接下来,进程会试图选举出来一个新的Leader,Leader切换为LEADING状态,其它进程发现已经选举出新的Leader,那么它就会切换到FOLLOWING状态,并开始与Leader保持同步。
3.处于FOLLOWING状态的进程称为Follower,LEADING状态的进程称为Leader。
4.当Leader崩溃或者放弃领导地位时,其余的Follower进程就会切换到LOOKING状态开始新一轮的Leader选举。
运行过程中的状态转换
一个Follower只能和一个Leader保持同步,Leader进程和所有的Follower进程之间通过心跳监测机制来感知彼此的情况。
1.若Leader能够在超时时间内正常的收到心跳检测,那么Follower就会一直与该Leader保持连接。
2.如果在指定时间内Leader无法从过半的Follower进程那里接收到心跳检测,或者TCP连接断开,那么Leader会放弃当前周期的领导,并转换为LOOKING状态;其他的Follower也会选择放弃这个Leader,同时转换为LOOKING状态,之后会进行新一轮的Leader选举
ZAB的四个阶段
选举阶段(Leader Election)
节点在一开始都处于选举阶段,只要有一个节点超过半数阶段的票数,它就可以当选准Leader,只有到达第三个阶段(同步阶段),这个准Leader才会成为真正的Leader。
这一阶段的目的就是为了选出一个准Leader,然后进入下一阶段。
发现阶段
在这个阶段中,Followers和上一轮选举出的准Leader进行通信,同步Followers最近接受的事务Proposal。这个阶段主要目的是发现当前大多数节点接受的最新提议,并且准Leader生成新的epoch,让Followers接受,更新它们的acceptedEpoch。
一个Follower只会连接一个Leader,如果有一个节点F认为另一个Follower P是Leader,F在尝试连接P时会被拒绝,F被拒绝后,就会进入选举阶段。
同步阶段
同步阶段主要是利用 Leader 前一阶段获得的最新 Proposal 历史,同步集群中所有的副本。
只有当 quorum(超过半数的节点) 都同步完成,准 Leader 才会成为真正的 Leader。Follower 只会接收 zxid 比自己 lastZxid 大的 Proposal。
广播阶段
到了这个阶段,Zookeeper 集群才能正式对外提供事务服务,并且 Leader 可以进行消息广播。同时,如果有新的节点加入,还需要对新节点进行同步。需要注意的是,Zab 提交事务并不像 2PC 一样需要全部 Follower 都 Ack,只需要得到 quorum(超过半数的节点)的Ack 就可以。
ZAB协议实现
Java 版本的ZAB协议的实现跟上面的定义略有不同,选举阶段使用的是 Fast Leader Election(FLE),它包含了步骤2的发现职责。因为FLE会选举拥有最新提议的历史节点作为 Leader,这样就省去了发现最新提议的步骤。
实际的实现将 发现和同步阶段合并为 Recovery Phase(恢复阶段) ,所以,Zab 的实现实际上有三个阶段。
快速选举(Fast Leader Election)
前面提到的 FLE 会选举拥有最新Proposal history (lastZxid最大)的节点作为 Leader,这样就省去了发现最新提议的步骤。 这是基于拥有最新提议的节点也拥有最新的提交记录
成为Leader的条件:
1.选epoch最大的
2.epoch相等,选zxid最大的
3.epoch和zxid都相等,选server_id最大的(zoo.cfg 中配置的 myid)
节点在选举开始时,都默认投票给自己,当接收其他节点的选票时,会根据上面的 Leader条件 判断并且更改自己的选票,然后重新发送选票给其他节点。当有一个节点的得票超过半数,该节点会设置自己的状态为 Leading ,其他节点会设置自己的状态为 Following。
恢复阶段(Recovery Phase)
这一阶段 Follower 发送他们的 lastZxid 给 Leader,Leader 根据 lastZxid 决定如何同步数据。这里的实现跟前面的 阶段 3 有所不同:Follower 收到 TRUNC 指令会终止 L.lastCommitedZxid 之后的 Proposal ,收到 DIFF 指令会接收新的 Proposal。
history.lastCommittedZxid:最近被提交的提议的 zxid history.oldThreshold:被认为已经太旧的已提交提议的 zxid
广播阶段(Broadcast Phase)
参考 4.1 [ZAB协议内容#消息广播]
ZAB与Paxos的联系和区别
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录大纲截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且后续会持续更新
如果你觉得这些内容对你有帮助,可以添加V获取:vip1024b (备注Java)
最后
经过日积月累, 以下是小编归纳整理的深入了解Java虚拟机文档,希望可以帮助大家过关斩将顺利通过面试。
由于整个文档比较全面,内容比较多,篇幅不允许,下面以截图方式展示 。
由于篇幅限制,文档的详解资料太全面,细节内容太多,所以只把部分知识点截图出来粗略的介绍,每个小节点里面都有更细化的内容!
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
-1712776860657)]
由于篇幅限制,文档的详解资料太全面,细节内容太多,所以只把部分知识点截图出来粗略的介绍,每个小节点里面都有更细化的内容!
一个人可以走的很快,但一群人才能走的更远。不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎扫码加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
[外链图片转存中…(img-iitQF9iN-1712776860657)]