ZAB协议

一、什么是Zookeeper?

ZooKeeper是一个集中的服务,用于维护配置信息、命名、提供分布式同步和提供组服务。提供高性能协调服务。
ZooKeeper 实施非常重视高性能、高可用性、严格有序的访问。操作简单,执行迅速。采用主从的模式搭建集群,集群角色分为:leader和follower,只有leader可以进行写操作。
数据是保存在内存中的。
在这里插入图片描述

1.1 数据模型

ZooKeeper内部数据模型以目录树的形式呈现。
在这里插入图片描述

1.2 保证

  • 顺序一致性 - 来自客户端的更新将按照它们发送的顺序应用。
  • 原子性 - 更新成功或失败。没有部分结果。
  • 单一系统映像 - 客户端将看到相同的服务视图,而不管它连接到的服务器如何。即使客户端故障转移到具有相同会话的不同服务器,客户端也永远不会看到系统的旧视图。
  • 可靠性 - 应用更新后,它将从那时起持续存在,直到客户端覆盖更新。

由于采用主从模式,采用一个leader,那么一定存在单点故障问题;为了保证整个集群的高可用,ZK的故障恢复很快,选举leader的时间压测为200ms

  • 及时性——系统的客户视图保证在一定的时间范围内是最新的。

读取节点数据的时候,可以通过sync同步leader中的数据,保证数据是最新的; ZK为了保证高可用,维护的是最终一致性。

二、ZAB

2.1 ZK的配置文件

在这里插入图片描述

其中:
3888 用于节点选择leader进行通信
2888 用于leader与其他follower进行通信

2.2 什么是ZAB

ZAB协议又称为 Zookeeper 原子广播协议,用于Zookeeper崩溃恢复场景,维持集群各副本数据一致性

当leader崩溃或者集群中参与选票的个数不足一半,表示整个集群对外服务不可用,需要进行崩溃恢复。

在上面的配置文件中,最后配置集群部分的server.id,id值越高表示称为leader的优先级越高,并记录在文件myid中;整个选举投票参照zxid和myid

2.3 ZXID

ZXID表示事务ID, 为了保证事务的顺序一致性,zookeeper采用了递增的事务id号(zxid)来标识事务。所有的提议(proposal)都在被提出的时候加上了zxid;当提议通过后,会修改zxid的后32位进行依次递增;

一旦提议提交成功,那么这个zxid的就是完全可信的;也就是说,保留全局最大zxid的表示的当前所有已经提交的事务,因此他保存的数据也是最完整的。

2.4 执行流程

2.4.1 leader选取

  • 当集群启动的时候,zxid都是0,因此投票选取由myid决定,使用3888端口进行通信投票,最后选取myid最大的为leader
  • 当leader失效,或者集群不可用的时候(投票数达不到一半以上),对外服务不可用;然后重新选取leader
  • leader宕机后,等待某一个服务器(称为A)心跳检测到leader状态,然后开始通知其他物理节点,进入投票阶段
  • A发送带有自己zxid的信息发送给其他人,其他人拿到后与自己的zxid进行比较。每一个结点都维护一个记录投票数的表
  • 比对投票表,将得数超过一半的并且myid大的选择称为新的leader
    在这里插入图片描述

2.4.2 如何维护可靠性?

当客户端的某一个请求到达时(无论连接哪个物理节点),如果是写操作,整个请求过程一定会经过一次leader,由leader发起选票决定这次提议是否通过;整个过程包括 投票阶段 和 提交阶段
对于两阶段提交,一般是维护强一致性,但是对于ZK为了保证高可用,使用选票达到一半以上即通过来维护最终一致性。

  1. 当直接请求leader,有leader发起选票,通过广播的形式发送给其他结点
  2. follower在接收到leader的提议时,首先在自己的日志中记录这次提议,然后返回leader一个ok的请求
  3. 当leader得到超过集群一半的选票时,提议成功,再次广播follower进行提交操作
  4. follower收到commit的请求,将数据加载到内存中
  5. 如果客户端请求的是follower,那么先有follower先将请求发送给leader然后进入投票阶段,成功后再反馈给用户

在这里插入图片描述
怎么维护的可靠性?
整个过程维护的是最终一致性,即一段时间后的所有节点数据是一致的即可。对于commit阶段尽管失败了,在ZK客户端中也存在sync的指令,可以先于leader进行同步。
上图中的队列用于维护请求的有序性(这里还没理解好,后续补)

总结

总结ZAB是什么?考虑如下;

  1. 集群启动初期怎么选择leader
  2. 服务不可用时候怎么选择leader

为什么leader的恢复速度很快?

  • ZK的快速来自于它在选取新leader的时候,即使没有心跳检测截止的follower也会因为其他人发送的信息而进入被动的投票阶段
  • 其次,在ZK中zxid的最大值保证了当前zxid执行的提议一定是成功的。因此这些数据不能丢失,新的投票以最大zxid为主。

疑问:
集群通信也是通过网络的,难道不会因为丢包而导致数据延迟吗?

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值