暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

zookeeper原子广播协议

程序猿研习社 2021-09-06
841
zookeeper是什么?
分布式一致性协调服务,由雅虎公司创建,设计目标是,将那些复杂且容易出错的分布式一致性服务封装起来,并提供给用户一套简单的接口就可以使用,分布式服务基于zookeeper可以实现很多功能如:发布/订阅、Master选举、分布式锁、分布式队列等...
分布式服务说:我想生成一个全局递增的标识太难了
zookeeper说:找我啊(顺序节点)
集群说:我们每次选老大(Master)都太难了
zookeeper说:找我啊(谁创建的临时节点最小谁就是老大)
......



ZAB
Zookeeper Atomic Broadcast 缩写,原子广播协议,它是专门为zookeeper设计的用来崩溃恢复和消息广播的协议,所以zab协议包括两种模式即:崩溃恢复模式和消息广播模式
  • 当Leader崩溃、整个zookeeper服务刚启动、或者有新加入集群的Follower等,就进入崩溃恢复模式
  • 当崩溃恢复之后,服务就进入了正常的消息广播模式

消息广播
在整个消息广播过程中,zab会为每个客户端事务请求生成一个Proposal,Leader为每个Follower准备一个FIFO队列,Leader将没个Proposal放入队列中依次发送,Follower在收到Proposal时,会先以事务日志的形式将Proposal保存下来,保存成功后会返回Leader一个ACK,当Leader收到过半的Follower的ACK后,就将事务提交同时生成一个Commit消息发送个Follower,让Follower将事务也提交;(Follower收到Commit后并不需要发送ACK)

崩溃恢复
如上面说的,当Leader挂了或者集群刚启动时等情况,zab就处于崩溃恢复模式,该模式需要有两个保证:
  • 保证已经在Leader上提交的事务都提交
  • 保证丢弃那些只在Leader上生成的Proposal

保证已经在Leader上提交的事务都提交

保证丢弃那些只在Leader上生成的Proposal

数据同步
针对上面两种情况:当产生新Leader时,只要让新Leader拥有集群中最大的事务id就可以了,(因为拥有最大事务id的节点拥有最全的数据,每个Proposal都对应一个递增的事务id),具体地:Leader会为每个Follower准备一个FIFO队列,并告诉Follower将那些没有被各他们提交的Proposal都提交了;(新领导上任,告诉属下把老领导交代的没完成的任务都收尾了抓紧)

上图这种属于正常情况下的数据同步,如何在旧Leader恢复之后,保证丢弃那些只在旧Leader上生成的Proposal?答案是这样的:
zookeeper的事务id是64位的数字,低32位是一个递增计数器,每来一个事务都递增一次;高32位代表Leader周期epoch编号,每当选新Leader,就会在原Leader的epoch基础上加1,做为新Leader的epoch,epoch可以理解为:选县里干部时的“界、任”,第几届领导,第几任县长;
基于这样的策略,当旧Leader崩溃恢复后,只在它那有的Proposal肯定不好使了,因为已经有新Leader了,新Leader会让其丢弃该Proposal,并回到上一个已被至少半数Follower提交的Proposal去;
(原县长因为贪污被抓了,等放出来的时候说话那肯定不好使了




文章转载自程序猿研习社,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

评论