ZooKeeper与ZAB一致性算法
- 简述ZAB协议以及ZooKeeper?
- 简述Paxos算法
- ZooKeeper的某个机器挂了,整个集群如何处理?
- 简述ZooKeeper的fastleaderelection选举leader的算法。
- ZooKeeper如何保证数据的一致性?
- ZooKeeper的监听原理?
ZooKeeper工作机制及其特点
1.简述ZAB
协议以及ZooKeeper?
Zookeeper
是一个高可用强一致的分布式协调服务,基于ZAB协议实现了一个主从一致的架构模式来保证数据的一致性。
zookeeper
= 文件系统 + 通知机制
Zookeeper
是一个基于主从一致的高可用集群,他的节点主要有几种角色:Leader
、Follower
、Observer
-Leader
:一个集群只有一个Leader
,负责写数据,处理数据同步的主节点,所有的数据写入必须先通过Leader再广播同步到所有的Follower
-
Follower
:负责存储数据,负责数据的读操作的节点。 -
Observer
:角色与Follower
类似,但是无投票权,负责与用户对接,将请求转发给Leader
。
ZAB
协议全称为:(Zookeeper Atomic Broadcast )Zookeeper原子广播协议
ZAB
主要有两种模式:崩溃恢复模式、协议广播模式
- 崩溃恢复模式:在
Zookeeper
集群服务刚启动,和Leader
挂掉的时候,就会启动崩溃恢复模式,主要是用于选出Leader
。 - 协议广播模式:在有
Leader
的情况,就处于协议广播模式,所有的写入操作都经过Leader
,并以类似二阶段提交的方式,写到Follower
中去,在此过程中,Leader
需要是不是接收来自Follower
的心跳,若没有检测到来自超过半数的Follower
心跳,或者TCP
连接短开了,当前Leader
放弃对当前周期的领导,Follower
与Leader
都进入Looking
状态。
进一步可以细分三个阶段:
- 发现(
Discovery
):投票竞选Leader
过程 - 同步(
Synchronization
)(容易遗漏的点):Leader
刚上任,需要把自己节点上的数据同步到所有的Follower
- 广播(
Broadcast
):服务开发,写入新的数据到Follower
2. 简述Paxos
算法
Paxos
算法是模拟了一个希腊城邦的提案的算法,一种是Basic Paxos
,另一种是Multi Paxos
。
-
Basic Paxos
:-
主要角色:
Client
(用户)、Proposer
(提议者)、Acceptor
(议会议员)、Learning
(提案记录者)。 -
流程:
client
将提案给到Proposer
,Proposer
初步地询问Acceptor
我们将来讨论这个提案号为N的提案,大多数议员通过后,Proposer
将提案分发给Acceptor
,Acceptor
成功接收了提案后,通知Proposer
和Learning
,Learning
再次备份提案。在此期间有更新的提案提出,之前的提案都会被打断。
-
-
Multi Paxos
:-
相比较
Basic
版本,多了一个选出leader
的环节,此时的Paxos
已经与ZAB
协议很相似了。 -
主要角色:
Client
(用户)、Server
(议员) -
流程:
Client
提交提案给其中一个Server
,那个Server
先询问所有的Server
竞选领导,若大多数同意则晋升,晋升Leader
后,可以直接发送提案给所有的Server
,让他们进行同步,若Leader
一直未过期,则不必继续竞选下一轮Leader
。
-
3. Zookeeper的某个机器挂了,整个集群如何处理?
-
若挂掉的机器是
Follower
,只要剩下的机子超过半数,则仍然可以工作。 -
若挂了的机器为
Leader
:ZAB协议进入了崩溃恢复模式,暂停对外服务,进行leader
选举(进入发现阶段)。每个Follower
都进入Looking
状态,每个Looking
状态的Follower
会发起一个投票,每个Follower
第一轮都会投自己,然后再根据 1⃣️zxid
最大的(证明事务是最新的,数据完善),2⃣️若zxid
一致,则选myid
最大的,选出Leader
,进入同步阶段,当超过一半的节点同步完成后,Leader
才算正式上任。
4. 简述Zookeeper的fastleaderelection
选举leader
的算法。
假设有 5 台服务器组成的 zookeeper
集群,它们的 id 从 1~5,同时它们也是最新启动的,也就是说没有历史数据,假设这些服务器按照顺序依次启动
-
服务器 1 启动,此时只有它一台服务器启动了,他发出去的报文没有任何响应,所以它的选举状态一直是
looking
的状态 -
服务器 2 启动,它与最开始启动的服务器 1 进行通信,互相交换自己的选举结果,由于两者都没有历史数据,所以
id
值较大的服务器 2 胜出,但是由于没有达到超过半数以上的服务器都同意选举它(这个例子中的半数以上是 3),所以服务器 1、2 还是继续保持looking
状态。 -
服务器 3 启动,根据前面的理论分析,服务器 3 成为服务器1、2、3中的老大,而与上面不同的是,此时有三台服务器选举了它,所以它成为了这次选举的
Leader
。 -
服务器 4 启动,根据前面的分析,理论上服务器 4 应该是服务器 1、2、3、4中最大的,但是由于前面已经有半数以上的服务器选举了服务器3,所以它只能接收当小弟的命了。
-
服务器 5 启动,同 4 一样当小弟
5. Zookeeper如何保证数据的一致性?
数据一致性的处理发生在同步阶段和广播阶段。
-
同步阶段:
重新选举出来的新的
Leader
,需要将自己节点上的信息同步到所有的Follower
上,只有当超过半数的Follower
同步成功时,新的Leader才能算上任。同步检验的方式是:通过Follower
上最大的zxid来比较新的Leader上的zxid是否一致。 -
广播阶段(二阶段提交):
Leader
发送事务请求到所有的Follower
,需要收到半数以上的Follower
的回应才能算此次事务写入成功,并向所有的Follower
发出Commit
指令,为了防止有些指令无法到达Follower
,Leader
会为每一个Follower
建立一个消息队列,将事务信息,与提交信息都放入队列中,保证事务的顺序性。
6. Zookeeper的监听原理?
源码解析
- 首先需要有一个主线程。
- 主线程内有两个线程
SendThread
线程,与EventThread
监听器线程 SendThread
线程负责与Zookeeper
集群通信EventThread
负责监听响应请求SendThread
将监听器的信息与监听的事件发送给Zookeeper
集群,Zookeeper
将信息添加到列表中- 当监听的对象发生变化后,
Zookeeper
发送消息给监听器 - 监听器线程调用
Process()
方法处理相关业务逻辑
关注我的公众号、了解更多有关于学习的文章
微信公众号:艾迪威姆 / PositiveEddie