zookeeper分布式协调工具工作原理以及选举流程

此生再无相见时 提交于 2020-01-29 11:38:37

1、zookeeper一致性原理

一致性概念:强一致性、弱一致性、最终一致性

为了保证主从节点的数据一致性,Zookeeper 采用了 ZAB 协议,这种协议非常类似于一致性算法 Paxos和 Raft

什么是 ZAB

Zookeeper Atomic Broadcast,有效解决了 Zookeeper 集群崩溃恢复,以及主从同步数据的问题。

#ZAB 协议定义的三种节点状态

  • Looking :选举状态。
  • Following :Follower 节点(从节点)所处的状态。
  • Leading :Leader 节点(主节点)所处状态。

#最大 ZXID

最大 ZXID 也就是节点本地的最新事务编号,包含 epoch 和计数两部分。epoch 是纪元的意思,相当于 Raft 算法选主时候的 term。

#ZAB 的崩溃恢复

假如 Zookeeper 当前的主节点挂掉了,集群会进行崩溃恢复。ZAB 的崩溃恢复分成三个阶段:

Leader election

选举阶段,此时集群中的节点处于 Looking 状态。它们会各自向其他节点发起投票,投票当中包含自己的服务器 ID 和最新事务 ID(ZXID)。

接下来,节点会用自身的 ZXID 和从其他节点接收到的 ZXID 做比较,如果发现别人家的 ZXID 比自己大,也就是数据比自己新,那么就重新发起投票,投票给目前已知最大的 ZXID 所属节点。

每次投票后,服务器都会统计投票数量,判断是否有某个节点得到半数以上的投票。如果存在这样的节点,该节点将会成为准 Leader,状态变为 Leading。其他节点的状态变为 Following。

Discovery

发现阶段,用于在从节点中发现最新的 ZXID 和事务日志。或许有人会问:既然 Leader 被选为主节点,已经是集群里数据最新的了,为什么还要从节点中寻找最新事务呢?

这是为了防止某些意外情况,比如因网络原因在上一阶段产生多个 Leader 的情况。

所以这一阶段,Leader 集思广益,接收所有 Follower 发来各自的最新 epoch 值。Leader 从中选出最大的 epoch,基于此值加 1,生成新的 epoch 分发给各个 Follower。

各个 Follower 收到全新的 epoch 后,返回 ACK 给 Leader,带上各自最大的 ZXID 和历史事务日志。Leader 选出最大的 ZXID,并更新自身历史日志。

Synchronization

同步阶段,把 Leader 刚才收集得到的最新历史事务日志,同步给集群中所有的 Follower。只有当半数 Follower 同步成功,这个准 Leader 才能成为正式的 Leader。

自此,故障恢复正式完成。

#ZAB 的数据写入

Broadcast

ZAB 的数据写入涉及到 Broadcast 阶段,简单来说,就是 Zookeeper 常规情况下更新数据的时候,由 Leader 广播到所有的 Follower。其过程如下:

  • 客户端发出写入数据请求给任意 Follower。
  • Follower 把写入数据请求转发给 Leader。
  • Leader 采用二阶段提交方式,先发送 Propose 广播给 Follower。
  • Follower 接到 Propose 消息,写入日志成功后,返回 ACK 消息给 Leader。
  • Leader 接到半数以上ACK消息,返回成功给客户端,并且广播 Commit 请求给 Follower

ZAB 协议既不是强一致性,也不是弱一致性,而是处于两者之间的单调一致性(顺序一致性)。它依靠事务 ID 和版本号,保证了数据的更新和读取是有序的。

2、zookeeper集群选举原理

zk的工作原理-选举流程

zk的核心原子广播,这个机制保证了各个Server之间的同步,实现这个机制的协议叫做Zab协议。Zab协议有两种模式,分别是恢复模式(选主)和广播模式(同步) .当服务器启动或者leader崩溃以后,Zab进入一个恢
复模式,当Leader被选举出来以后,然后进行同步模式。
zxid:是一个64位的数字,高32位是epoch, 用来标志leader关系是否改变了,每一次新的leader选出来以后,都会用有一个新的epoch。 低32位用来递增计数。zxid越大,表示数据越新。
serverid:给定服务器标志的1d。
Epoch:选举的轮数

当Leader崩溃或者Leader失去了大多数的follower, zk进入恢复模式,然后选出一个新的leader

zk选举算法两种,一种是基于basic paxos实现,一种是基于fast paxos算法实现的。zk系统默认的是fast

server在工作过程中的三个状态:
LOOKING:当前server不知道Leader是谁,正在寻找。
LEADING:当前setver就是刚选举出来的leader.
FOLLOWDING: leader已经选出来了,当前server正在和它同步 .

basic paxos流程:
1、选举线程由当前server发起选举的线程担任, 主要是对投票结果进行统计,并选出推荐的server
2、选举线程首先向所有的server发起一次询问(包括自己)
3、选举线程收到回复以后,验证是否是自己发起的询问(验证zxid是否一致),然后获取对方的id,并存储到当前的询问对象列表里,最后获取对方提议的leader相关信息(myid, zxid) 。
4、收到所有的server回复以后,就计算出zxid最大的那个server,将这个server相关信息设置成下一个投票的server.
5、线程将当前的zxid最大的server设置成要推荐的leader,如果此时获胜的server获得n/2+1的server票数,这个server就获胜成为当前新的leader.
备注: server总数必须是奇数2n+1

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!