上次跟学弟学妹们聊完了Spring相关的一些知识点,学弟学妹们还是挺开心的,但是上次有学弟在跟我留言,在出去面试的时候被面试官问了个一脸蒙逼急的问题:
zookeeper你用过吗?作为注册中心它是怎么如何保证CP的呢?
为了对的起学弟学妹们的信赖这次跟大家具体聊聊zookeeper中的一致性选举算法Paxos算法
什么是CAP?
什么是三二原则?
Zookeeper与Eureka的区别?
言归正转,基础就跟大家聊到这里了,开始直接开始正文吧!!!
Paxos算法
算法前置理解
首先需要理解的是算法中的三种角色
- Proposer(提议者)
- Acceptor(决策者)
- Learners(群众)
一个提案的决策者(Acceptor)会存在多个,但在一个集群中提议者(Proposer)也是可能存在多个的,不同的提议者(Proposer)会提出不同的提案。
paxos算法特点:
Paxos算法整个选举的过程可以分为两个阶段来理解。
阶段一
这个阶段主要是准备阶段发送提议
阶段二
当前阶段要是真正的发送接收阶段又被称为Accept阶段
看到这里可能很多学弟都是一脸懵逼,什么鬼?为了加深理解,让整个过程更加的透明,还是举例说明一下吧!!!
假设现在我们有三台主机服务器从中选取leader(也可以选择其他的更多的服务器,为了比较方便容易理解这里选少一点)。所以这三台主机它们就分别充当着提议者(Proposer)、决策者(Acceptor)、Learners(群众)三种角色。
所以假设现在开始模拟选举,三台服务分别开始获取N(具有全局唯一性的、递增的提案编号 N)的值,此时 serverOne(主机1) 就对应这个 ProposerOne(提议者1)、serverTwo(主机2)对应ProposerTwo(提议者2)、serverThree(主机3)对应ProposerThree(提议者3)。
为了整个流程比较简单清晰,过程中更好理解。他们的初始N值就特定的设置为 ServerOne(2)、ServerTwo(1)、ServerThree(3),所以他们都要发送给提议(Proposal)给决策者(Acceptor),让它们进行表决确定
同时每个 提议者(Proposer)向其中的两个决策者(Acceptor)发送提案消息。所以假设:
ProposerOne(提议者1)向 AcceptorOne(决策者1)和AcceptorTwo(决策者2)、
ProposerTwo(提议者2)向AcceptorTwo(决策者2)和AcceptorThree(决策者3)、
ProposerThree(提议者3)向AcceptorTwo(决策者2)和AcceptorThree(决策者3)、
发送提案消息。为了流程结构简单就向其中的2台发送提案,但是也是已经超过半票了,当然也可以多选几个主机,多发送提案,只是流程就复杂了一点不好理解了。注意点就是一定要超过半票。
那么整个图可以如下所示:
所以根据上面的图开始走第一阶段
按照上面我们假设的流程开始执行流程
ProposerOne(提议者1)向 AcceptorOne(决策者1)和AcceptorTwo(决策者2)
ProposerTwo(提议者2)向AcceptorTwo(决策者2)和AcceptorThree(决策者3)
ProposerThree(提议者3)向AcceptorTwo(决策者2)和AcceptorThree(决策者3)
由于之前ProposerTwo(提议者2)向AcceptorTwo(决策者2)和AcceptorThree(决策者3)发出提议时,没有超过半数投票。所以会从新获取最大N值(具有全局唯一性的、递增的提案编号 N),这个时候ProposerTwo(提议者2)本地获取的N值为4所以会再次发起一轮投票
到此第一阶段的工作就已经完成了,整个流程都是文字较多,看起需要多看几遍。同时我也给大家画了一个流程图如下:
由于上面已经走完第一阶段,那么接下来肯定就是第二阶段的流程了
同时整体第二阶段可以分为两块来理解,第一块是正式提交提议,第二块是表决确定阶段
第一阶段执行完得到的结果:
第一块:
第二块:
总结
整个Paxos算法过程还是比较难理解,为了讲明白这里面的流程都是按最简单的例子来的。这里面也可以有更多的机器发起更多的提议。但是整个流程那就更难理解了。
理解Paxos算法需要按上面的两个阶段来理解。第一阶段是做什么,得到了什么结果,第二阶段又是基于第一阶段的结果执行怎样的一个选举流程,这个是大家需要思考的重点。
这里主要是跟大家分享的是Paxos算法这个选举过程,也有很多其他的优化版本比如 Fast Paxos、EPaxos等等。
Zookeeper
在zookeeper中的选举算法就是用的 Fast Paxos算法,为什么用Fast paxos?
ZAB(Zookeeper Atomic BroadCast)原子广播协议
所以在zookeeper中,只有一台服务器机器作为leader机器,所以当客户端链接到机器的某一个节点时
- 当这个客户端提交的是读取数据请求,那么当前连接的机器节点,就会把自己保存的数据返回出去。
- 当这个客户端提交的是写数据请求时,首先会看当前连接的节点是不是leader节点,如果不是leader节点则会转发出去到leader机器的节点上,由leader机器写入,然后广播出去通知其他的节点过来同步数据
在ZAB中的三类角色
- Leader:ZK集群的老大,唯一的一个可以进行写数据的机器。
- Follower:ZK集群的具有一定职位的干活人。只能进行数据的读取,当老大(leader)机器挂了之后可以参与选举投票的机器。
- Observe:最小的干活小弟,只能进行数据读取,就算老大(leader)机器挂了,跟他一毛关系没有,不能参与选举投票的机器。
在ZAB中的三个重点数据
- Zxid:是zookeeper中的事务ID,总长度为64位的长度的Long类型数据。其中有两部分构成前32位是epoch后32位是xid
- Epoch:每一个leader都会有一个这个值,表示当前leader获取到的最大N值,可以理解为“年代”
- Xid:事务ID,表示当前zookeeper集群当前提交的事物ID是多少(watch机制),方便选举的过程后不会出现事务重复执行或者遗漏等一些特殊情况。
zookeeper中的一些知识点就分享到这里了,因为这里面还有很多很多东西,比如Session 、Znode、Watcher机制 、ACL、三种状态模式 还zookeeper怎么实现分布式事务锁等等。没有办法一次性跟大家聊完。
这次主要还是想让学弟学妹了解清楚Zookeeper中的一致性的算法是怎么保证。
结尾
针对面试来说能完全的跟面试官讲明白这个一致性算法,那你就已经走在前面了。整个过程还是比较复杂的,需要自己不断的多看多画图理解。
在这个互联内卷的时代,只有懂得比别人多才能走的比别人远。
最后希望我的学弟学妹们都能有一个好的校招结果!!!