Zookeeper之Zab协议

Posted 2021-04-13 大数据DL

一、Zookeeper简介

二、Zab协议

一、Zookeeper简介

Zookeeper 是一个开放源代码分布式协调服务，雅虎创建。是Google Chubby的开源实现，与Chubby不同的是Chubby完全是 Paxos协议的工程实现，而Zookeeper 是ZAB协议的特定实现。

Zookeeper 分布式一致性的特点如下：

顺序一致性 ： 同一客户端访问 Zookeeper 的一个 节点，发起事务请求，严格按照发起顺序应用到Zookeeper。

单一视图 ： 任何节点上的数据都是一样的，所以客户端访问任意节点 都是看到是相同的数据。

可靠性： 一旦服务端成功应用了一个事务，并完成响应，那该事务引起的服务端变更会一直保留下来，除非另一个事务对其进行了变更。

实时性：Zookeeper保证在一定时间内，比如5秒之后你可以访问到最新数据。

Zookeeper设计目标：

简单的数据模型： 就是文件夹的树形结构。

可以构建集群： 肯定是可以，不可以那还叫分布式吗。集群模式示意图：

顺序访问：客户端提出了一个事务请求会获得一个唯一的id编号用于操作的先后顺序。

高性能： 这里指的是读取数据 。

Zookeeper基本概念：

集群角色：Leader， Follower ，Observer，集群中所有机器通过选举过程选举Leader机器，Leader服务器为客户端提供读写服务，Follower和Observer也可以可以提供读服务，区别在于Observer不参与Leader选举过程

数据节点（Znode）：节点分两类，第一种是构成集群的机器成为机器节点，另一种是数据模型中的数据单元，称为数据节点Znode，Zookeeper将所有数据存储在内存中，数据模型是一棵树，由斜杠进行分割的路径就是一个Znode,例如/a,Znode保存自己的数据内容，并且保存一系列属性信息。

Znode分为持久节点和临时节点，持久节点指的是一旦被创建，除非主动移除，不然就会一直存在，临时节点指的是与此绑定的客户端会话一旦失效，客户端创建的所有临时节点都会被移除。

watcher 监听机制 ：Zookeeper有watcher 监听机制，在一些特定事务发生时可以触发一些操作。例如 你注册了一个临时数据节点，如果你客户session中断了，临时节点就删除了， 这时 watcher就监听到了，通知实现了代码

ACL：类unix文件系统的权限控制，定义了以下5种控制权限

CREATE:创建子节点权限

READ:获取节点数据和子节点列表权限

WRITE:更新节点数据权限

DELETE:删除子节点权限

ADMIN:设置节点ACL权限

其中CREATE和DELETE都是针对子节点的权限。

二、Zab协议

Zab 中的 三种状态：

1. Looking ：系统刚启动时或者Leader崩溃后正处于选举状态

2. Following ：Follower节点所处的状态，Follower与Leader处于数据同步阶段；

3. Leading ：Leader所处状态，当前集群中有一个Leader为主进程；

ZooKeeper启动时所有节点初始状态为Looking，这时集群会尝试选举出一个Leader节点，选举出的Leader节点切换为Leading状态；当节点发现集群中已经选举出Leader则该节点会切换到Following状态，然后和Leader节点保持同步；当Follower节点与Leader失去联系时Follower节点则会切换到Looking状态

，开始新一轮选举；在ZooKeeper的整个生命周期中每个节点都会在Looking、Following、Leading状态间不断转换；

当启动后Leader 崩溃选举：

选举出Leader节点后ZAB进入原子广播阶段，这时Leader为和自己同步的每个节点Follower创建一个操作序列，一个时期一个Follower只能和一个Leader保持同步，Leader节点与Follower节点使用心跳检测来感知对方的存在；当Leader节点在超时时间内收到来自Follower的心跳检测，那Follower节点会一直与该节点保持连接；若超时时间内Leader没有接收到来自过半Follower节点的心跳检测或TCP连接断开，那Leader会结束当前周期的领导，切换到Looking状态，所有Follower节点也会放弃该Leader节点切换到Looking状态，然后开始新一轮选举；

zab 宏观上的 三个阶段：崩溃恢复、快速选举、原子广播；

zab 的 微观上的 四个阶段： 选举 、（恢复分成发现和同步） 发现、同步、广播

第一阶段：准备 leader 选举，成为 leader 的条件：选epoch最大的，当epoch相等时，选 zxid最大的，当epoch和zxid都相等，选择serverid最大的（就是我们配置zoo.cfg中的myid），节点在选举开始都默认投票给自己，当接收其他节点的选票时，会根据上面的条件更改自己的选票并重新发送选票给其他节点，当有一个节点的得票超过半数，该节点会设置自己的状态为 leading，其他节点会设置自己的状态为 following。

注：zxid 是64位,前32位是当前leader编号也就是epoch，后32位是这个leader下事务编号zxid，当Leader重新选举后，epoch会加1，后32位的事务编号会清零并从0开始。

第二阶段：发现阶段 主要是发现最大的epoch 和最大的事物编号

第三阶段 就是 同步数据，leader 利用上个阶段知道最大事物编号， 然后通知 其它 fllower去leader这同步数据。

第四阶段 ：  原子广播阶段，这时候 leader 正真对外提供服务接受客户端的请求，生成 一个事务，半数以上同意 然后 就提交事物，剩下的其它节点直接去 leader 那同步数据。

总结：

选举 、发现、同步这几个阶段中是 looking 状态，当这些结束后是Leader  和Fllower 状态，这个过程是 广播状态。也就是客户端提交一个请求到 leader然后 leader发起提议 fllower来投票 ，这个整个过程都是原子广播。我们可以笼统的称它有两个阶段： 恢复和广播

把 选举 、发现 、同步 统称为恢复 leader---也就是 产生leader 的过程，当产生完 leader 然后 就可以接受客户端做出提议的过程叫做原子广播。