Zookeeper 的恢复模式,广播模式,选举流程

知识需要反思,复述。

阅读文本大概需要 3 分钟。

背景:

作为高可用一致性协调框架的老大哥,“动物界的管理员”,zookeeper 肯定有自己的一致性算法,叫做 ZAB,全称是 Zookeeper Atomic Broadcast ,翻译过来叫做原子消息广播协议。

由来:

这个算法是基于 paxos 扩展而来的,设计了崩溃恢复模式,zk 使用单一主进程 leader 来处理客户端所有的事务请求,采用ZAB协议将服务器数状态以事务形式广播到所有Follower上。

ZAB 的两种模式:

恢复模式:ZAB协议支持的崩溃恢复可以保证在Leader进程崩溃的时候可以重新选出Leader并且保证数据的完整性;

什么时候会进入恢复模式呢?

1.集群刚刚启动的时候。

2.leader 因为故障宕机了。

3.leader 失去了半数的机器支持。

消息广播模式:在ZooKeeper中所有的事务请求都由一个主服务器也就是Leader来处理,其他服务器为Follower,Leader将客户端的事务请求转换为事务Proposal,并且将Proposal分发给集群中其他所有的Follower,然后Leader等待Follwer反馈,当有过半数(>=N/2+1)的Follower反馈信息后,Leader将再次向集群内Follower广播Commit信息,Commit为将之前的Proposal提交。

图是从网上找的,图画的很清晰,一个客户端的写请求进来之后,leader 会为每个客户端的写请求包装成事务,并提供一个递增事务ID(zxid),保证每个消息的因果关系顺序。leader 会为该事务生成一个 Proposal,进行广播,leader 会为每一个 Follower服务器分配一个单独的FIFO 队列,然后把 Proposal 放到队列中,每一个 Follower 收到 该 Proposal 之后会把它持久到磁盘上,当完全写入之后,发一个 ACK 给leader,我们的leader 也不傻,收到超过半数机器的ack之后,他自己把自己机器上 Proposal 提交一下,同时开始广播 commit,每一个 Follower 收到 commit 之后,完成各自的事务提交。

可见,多数派机制和 ack 机制保证了 zk 的效率和可靠性。

特殊情况崩溃的处理:

已经被 leader 提交的 Proposal 确保最终被所有的 Follower 提交。

确保只有在 leader 上被提出的 Proposal 会被遗弃。

这里的丢弃事务是如何让进行的呢?我们知道,每一个事务都是有一个 zxid进行标记的,这个zxid 是一个 64位的数字,低32位做为计数器,高32位作为 leadert 的epcho周期、重新选举出来的 leader 会在急集群中找到最大的日志的 zxid,然后提取出来 + 1 作为自己的 epcho 周期数,然后把后面的32位清零,开始计数。

选举流程:

假设目前有五台服务器,每台服务器均没有数据,编号分别是 1,2,3,4,5,按照编号一次启动他们:

服务器1启动,给自己投票,然后发投票信息,由于其它机器还没有启动所以它收不到反馈信息,服务器1的状态一直属于Looking。

服务器2启动,给自己投票,同时与之前启动的服务器1交换结果,由于服务器2的编号大所以服务器2胜出,但此时投票数没有大于半数,所以两个服务器的状态依然是LOOKING。

服务器3启动,给自己投票,同时与之前启动的服务器1,2交换信息,由于服务器3的编号最大所以服务器3胜出,此时投票数正好大于半数,所以服务器3成为领导者,服务器1,2成为小弟。

服务器4启动,给自己投票,同时与之前启动的服务器1,2,3交换信息,尽管服务器4的编号大,但之前服务器3已经胜出,所以服务器4只能成为小弟。

服务器5启动,后面的逻辑同服务器4成为小弟。

这样,服务器3成为了 leader !

基于上面的选举流程,试想如果是启动顺序按照服务器 5,4,3,2,1 ,谁会是 leader 呢?

ps:这里的编号指的是:myid 文件里对应的编号。

答案是:服务器 5

思维导图:

需要源文件的,可以后台联系我,加我微信获取。

如果对您有帮助,欢迎点赞、关注、转发。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181203G1OBD200?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券