写给自己的Zookeeper学习笔记

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/qq_34993631/article/details/83831471

这时大数据技术栈的开端

Zookeeper

Zookeeper是干什么的?

Zookeeper是一个分布式协调框架,他可以

①实现集群管理(由于它自身的集群通信机制比如说为每一个集群节点建立一个临时节点在这个节点down机之后临时节点会销毁),

②集群的统一配置管理(由于它的数据一致性)

③统一命名服务(由于它内部维护的znode树)的节点是不能够重复的。

④实现分布式屏障(这个就像栅栏一样,实时监测就绪的数据节点以便下一步的操作)

⑤实现分布式锁(这个就是在多个客户端发起资源的请求时我们只服务事务id最小的那个,以免造成资源的争抢)

⑥实现数据的订阅和发布(这个就是让客户端监听znode节点当数据更新时就可以自动获取消息)

 

Zookeeper的数据结构

Zookeeper内部维护的一些节点,他们构成了树的结构。我们可以把它想成是数据结构中的树。如下图所示

根节点是/,每一个节点都可以存储数据,并且每个节点都是唯一的。这也就可以令每个节点对应一台主机这样的话也就能够提供统一命名服务了。

我们可以根据不同的参数去创建不同的节点一般有如下归类:

Zookeeper的其它组成关键词

事务日志

每当客户端访问zk集群的时候zk内部就会产生一条新的日志,而且这些日志的编号(也就是日志id号)就会增加1。这样事务日志也就能够记录下客户端访问zk集群的整个流程也就形成了日志文件。需要注意的是这里的事务日志id是全局递增的。

 

快照文件

快照文件就是对zk集群的一次状态的记录。拍摄快照的时间点在更换了新的领导时,或者默认情况下是每增加10万条的事务id就会拍摄一次快照。

 

EpochId

Zk的事务id是一个64位的二进制数,高32位是EpichId低32位是递增的事务id。EpochId可以防止脑裂(也就是在同一时刻出现两个leader的情况)。采用的策略是让Follower只选择接受EpochId高的leader。需要注意的是EpochId跟换之后所有的事务ID又会从0开始来计数。

 

Zookeeper的选举机制

当一个节点启动时它会经历下面的步骤:

1.数据恢复阶段

这一节点当前的zk会检查选择自己最大的事务id也就是最新的事务,然后进行比较。

2.选举阶段

每个zk都会提交自己的一个数据包

数据包中包括:

①自己所拥有的最大事务id是Zxid。

②自己的选举ID(也就是自己在myid文件中写的数字)

③逻辑时钟值确保多台的zk服务器在同一时间内进行选取。

⑤自己当前的状态包括looking(正在选举的状态)、leader(领导者)、follower(跟随者)、observer(观察者)。

具体的比较规则就是首先比较自己的事务id,因为事务id越大意味着自己有越新的数据。它当选为leader就可以将自己的数据同步到其它的follower上面。

如果事务ID相同的话那么就比较自己的选举ID。需要注意的是如果过半的服务器达成一致的话那么就选举有效。这也就引出了过半存活的策略,必须要有过半的机子存活如果没有的话那么就无法满足过半选举的条件。Zk集群也就无法启动。

 

Zookeeper的数据一致性

Zk集群必须保证数据的一致性,也就是zk集群中每台机子上的数据都必须一样。

关键词:原子广播实现数据一致性的策略

客户端在访问zk集群时zk集群会直接或者间接的将请求转发给zk集群中的leader(也就是说其它非leader接收到请求就会转发该请求)。Leader收到这个请求之后开始将他执行。然后再将这个请求以事务的形式(如果是多次请求的话就是事务队列的形式,而且他们是按照事务id排好序的)发送给其它的节点,进而实现数据的同步。其中为了保证数据一致性的可靠性,我们使用了ZAB(zookeeper atomic boardcast)zk原子广播算法来解决这个问题。

它是2pc算法的升级版下图先介绍2pc算法:

这里我们可以看出事务的执行和事务的提交是两个不同的阶段。在2pc当中当所有的事务执行成功并且返回的yes时候leader会将这次的事务commit。但是这种策略过于保守效率低下,在ZAB中采用了过半的策略也就是当有过半的服务器返回yes时leader就会让这个事务提交而不是回滚。这里总结一下ZAB的过半选举的应用:

①选举leader

②事务的提交

③存活机制

 

Zookeeper的奔溃恢复

当leader down机了会怎么办呢?

在2pc中并没有解决方案。但是在ZAB中任然使用了过半的策略来选举新的leader,比较规则与前面的类似。所以只要有过半的机器存活并且达成了一致性那么就会有新的leader诞生。这时Epochid就会改变与之对应的事务id也会从头来计数。

 

 

Zookeeper中的观察者

我门可以想象大量的follower会导致选举变得非常的困难,需要大量的通信与大量的计算。这样就大大降低的原子广播或者是选举的效率。但实务上我们有需要很多台机子来工作,这样也就诞生了zookeeper中的观察者Observer。Observer与follower最大的不同就是Observer不参与投票,而其他的类似。这就是说Observer能够提供服务而其他的投票工作可以交给leader与follower来处理。大大减少了网络通信与计算的次数与带宽。

 

Zookeeper配置相关

集群配置

在datadir下面创建myid里面是一个数字是自己的选举id。

 

观察者配置

到此zookeeper的核心概念也就介绍完毕了。

猜你喜欢

转载自blog.csdn.net/qq_34993631/article/details/83831471