Zookeeper原理详解(6大工作原理详细图解)

Zookeeper原理详解(6大工作原理详细图解)-mikechen

Zookeeper简介

Zookeeper原理详解(6大工作原理详细图解)-mikechen

ZooKeeper 是一个开源的分布式  协调服务框架,它是一个为分布式应用提供一致性服务的软件,是雅虎公司创建,是 Google 的 Chubby 一个开源的实现。

 

Zookeeper设计目标

设计目标主要包含4个:

目标一:简单的数据模型

ZooKeeper使得分布式程序能够通过一个树型结构的名字空间来进行相互协调。

这里所说的树型结构的名字空间,是指ZooKeeper服务器内存中的一个数据模型,其由一系列被称为ZNode的数据节点组成。

目标二:可以构建高可用

一个 ZooKeeper 集群通常由一组机器组成,一般 3~5 台机器就可以组成一个可用的ZooKeeper集群了。

使得分布式单点问题很好解决,而严格的顺序访问控制,使得客户端能够实现一些复杂的同步操作。

 

目标三:顺序访问

对于来自客户端的每个更新请求,ZooKeeper 都会分配一个全局唯一的递增编号,这个编号反映了所有事务操作的先后顺序。

 

目标四:构建高性能

由于ZooKeeper将全量数据存储在内存中,并直接服务于客户端的所有非事务请求,因此它尤其适用于以读操作为主的应用场景。

 

Zookeeper数据模型

Zookeeper 中的所有存储的数据是由 znode 组成的,节点也称为 znode,并以 key/value 形式存储数据。

整体结构类似于 linux 文件系统的模式以树形结构存储,其中根路径以 / 开头。

1.节点构造

如下图所示:

Zookeeper原理详解(6大工作原理详细图解)-mikechen

2.节点组成:

图中的每个节点称为一个Znode,每个Znode由3部分组成:

  1. stat:此为状态信息, 描述该Znode的版本权限等信息;
  2. data:与该Znode关联的数据;
  3. children:该Znode下的子节点;

 

3.节点类型

Znode主要包含4种类型:分别为临时节点、永久节点、序列化节点。

Zookeeper原理详解(6大工作原理详细图解)-mikechen

1.临时节点(Ephemeral )

节点的生命周期依赖于创建它们的会话,一旦会话结束,临时节点将被自动删除。

 

2.永久节点(Persistent )

该节点的生命周期不依赖于会话,并且只有在客户端显示执行删除操作的时候,他们才能被删除。

 

3.序列化节点(Sequence )

Znode还有一个序列化的特性,如果创建的时候指定的话,该Znode的名字后面会自动追加一个不断增加的序列号。

它的格式为10位数字,没有数值的数位用0补充,例如:0000000001。

 

4.临时顺序节点

基本特性同临时节点,增加了顺序属性,节点名后边会追加一个由父节点维护的自增整型数字。

 

Zookeeper通知Watch

客户端注册监听他关心的目录节点,当目录节点发生变化(数据改变、被删除、子目录节点增加删除)时,Zookeeper会通知客户端。

client端会对某个znode建立一个watcher事件,当该znode发生变化时,zk会主动通知watch这个znode的client,然后client根据znode的变化来做出业务上的改变等。

watch的整体流程如下图所示:

Zookeeper原理详解(6大工作原理详细图解)-mikechen

主要流程如下:

1.客户端先向Zookeeper服务端成功注册想要监听的节点状态。

2.同时客户端本地会存储该监听器相关的信息在WatchManager中。

3.当Zookeeper服务端监听的数据状态发生变化时,Zookeeper就会主动通知发送相应事件信息给相关会话客户端,从WatherManager中取出对应Wather对象执行回调逻辑。

 

Zookeeper工作原理

Zookeeper本身是一个集群结构,有一个leader节点负责写请求,多个follower负责响应读请求,并且在leader节点故障时会自动根据选举机制从剩下的follower中选出新的leader。

1.Zookeeper角色

Zookeeper原理详解(6大工作原理详细图解)-mikechen

1.leader

处理所有的事务请求(写请求),可以处理读请求,集群中只能有一个Leader

2. Follower

只能处理读请求,同时作为 Leader的候选节点,即如果Leader宕机,Follower节点要参与到新的Leader选举中,有可能成为新的Leader节点。

3. Observer

Observer:只能处理读请求,不能参与选举。

 

2.Zookeeper集群

Zookeeper原理详解(6大工作原理详细图解)-mikechen

集群为2N+1台,比如N为1的情况就是3台,为什么是3台而不是2台呢?因为集群需要一半以上的机器可用。

 

3.ZAB协议

Zab协议是为分布式协调服务Zookeeper专门设计的一种 支持崩溃恢复 的 原子广播协议 ,是Zookeeper保证数据一致性的核心算法。

Zab借鉴了Paxos算法但又不像Paxos那样,与Raft算法类似,是一种通用的分布式一致性共识算法。

Zab 协议的原理可细分为如下四个阶段:

Zookeeper原理详解(6大工作原理详细图解)-mikechen

1.Leader election(选举阶段)

节点在一开始都处于选举阶段,只要有一个节点得到超过半数节点的票数,它就可以当选准 Leader。

2.Discovery(发现阶段)

在这个阶段,Followers跟准Leader进行通信,同步Followers最近接收的事务提议。

3.Synchronization(同步阶段)

同步阶段主要是利用Leader前一阶段获得的最新提议历史,同步集群中所有的副本。同步完成之后准Leader才会成为真正的Leader。

4.Broadcast(广播阶段)

到了这个阶段,Zookeeper集群才能正式对外提供事务服务,并且Leader 可以进行消息广播,同时如果有新的节点加入,还需要对新节点进行同步。

 

Zookeeper工作模式

1.Zookeeper从设计模式的角度理解

Zookeeper:是一个基于观察者模式设计的分布式服务管理框架。

2.Zookeeper基于事件监听通知

监听注册到上面的节点的动向,比如:修改、新增、删除等,会实时的通知访问客户端。

Zookeeper原理详解(6大工作原理详细图解)-mikechen

3.Zookeeper选举机制

当leader崩溃或者leader失去大多数的follower,这时候zk进入恢复模式,恢复模式需要重新选举出一个新的leader,让所有的Server都恢复到一个正确的状态。

这里会涉及几大核心名字:SID、ZXID、VOTE、Quorum等,如下图所示:

Zookeeper原理详解(6大工作原理详细图解)-mikechen

选举的步骤,主要分为如下5步:

第一步:每个Server发出一个投票;

第二步:接收来自各个服务器的投票;

第三步:PK选票并更新选票;

第四步:统计所有投票,判断是否有过半机器接收到相同的投票信息;

第五步:改变服务器状态。

以上

关注「mikechen」公众号,获取更多技术干货!

后台回复【面试】即可获取《史上最全阿里Java面试题总结》,后台回复【架构】,即可获取《阿里架构师进阶专题全部合集

评论交流
    说说你的看法