首页 > 其他 > 详细

这也太简单了!!Zookeeper核心ZAB协议

时间:2021-03-29 14:07:03      阅读:15      评论:0      收藏:0      [点我收藏+]

ZAB协议是什么?

ZAB 协议全称:Zookeeper Atomic Broadcast(Zookeeper 原子广播协议), 它保证Zookeeper 在主从系统架构下,集群中各个节点之间数据的一致性。保证数据一致性的分两种情况讨论,一种集群正常运行,一种集群不正常。

Zookeeper集群正常运行时采用消息广播模式保证;

Leader节点宕机情况下采用崩溃恢复模式,保证;

消息广播

消息广播,就是集群正常运行时接收客户端写请求,需要保证集群数据的一致。
消息广播是一个原子广播协议,类似二阶段提交过程。主要3个步骤:

  1. Leader 接收客户端的写请求
  2. Leader 封装事物Proposal消息,广播给集群中的所有Follower,等待ACK响应
  3. 当Leader接收 Follwer的ACK响应数过半(当然包括自己),就commit自己本地数据,然后将commit请求广播给集群中的Follwer

消息广播大概流程如下:

技术分享图片
结合上图,看看消息广播的具体细节:

  • Leader 接收到请求后在进行广播事务 Proposal 之前会为这个事务分配一个 ZXID,再进行广播。

  • Leader 会为每个Follower都各自分配一个单独的队列,然后将需要广播的事务 Proposal 依次放入这些队列中去,并根据 FIFO 策略进行消息的发送。

  • 每个Follower 在接收到后都会以事务日志的形式写入到本地磁盘中,并且在成功写入后返回给 Leader一个 ACK 响应。

  • 当有超过半数的Follower ACK 响应后,Leader 就会广播一个 Commit 消息给所有的 Follower,Follower 接收到后就完成对事务的提交操作。

ZXID 的设计也很有特点,是一个全局有序的 64 位的数字,可以分为两个部分:

高 32 位是:epoch(纪元),代表着周期,每当选举产生一个新的 Leader 服务器时
就会取出其本地日志中最大事务的 ZXID ,解析出epoch(纪元)值操作加 1作为新的 epoch ,
并将低 32 位置零。

低 32 位是:counter(计数器),它是一个简单的单调递增的计数器,针对客户端的每个事务请求都会进行加 1

画个更详细的图:

技术分享图片

崩溃恢复

崩溃恢复,就是在Leader节点宕机的时候,重新选举出Leader后(关于选举机制可以参看这片文章),Follower 同步新Leader时,需要保证一致性。

在Leader节点宕机时,可能会发生2种情况,针对这两种情况我们来分析,它是怎么保证数据一致的。

  1. Leader 在广播事务 Proposal 给所有 Follwer 之后宕机,数据怎么处理?
  2. Leader 在收到 ACK 并commit自己,同时发送了部分 commit 出去之后宕机,数据怎么处理?

针对这2个情况,ZAB 定义了2个原则:

  1. ZAB 协议会保存那些被Leader广播Proposal且提交的事务。

  2. ZAB 协议会丢弃那些被Leader广播Proposal但没提交的事务。

说白了,就是Follwer接收到Leader的 commit请求的那些数据才有效。

在选举机制这篇文章,我们就可以确定出新的Leader节点数据一定是最新的。然后Follower就进行数据同步咯。

这也太简单了!!Zookeeper核心ZAB协议

原文:https://www.cnblogs.com/javajn/p/14591893.html

(0)
(0)
   
举报
评论 一句话评论(0
关于我们 - 联系我们 - 留言反馈 - 联系我们:wmxa8@hotmail.com
© 2014 bubuko.com 版权所有
打开技术之扣,分享程序人生!