之前的文章Zookeeper根底原理&利用场景详解中将Zookeeper的基本原理及其利用场景做了一个具体的介绍，尽管介绍了其底层的存储原理、如何应用Zookeeper来实现分布式锁。然而我认为这样也仅仅只是理解了Zookeeper的一点皮毛而已。所以这篇文章就给大家具体聊聊Zookeeper的外围底层原理。不太熟悉Zookeeper的能够回过头去看看。

ZNode

这个应该算是Zookeeper中的根底，数据存储的最小单元。在Zookeeper中，相似文件系统的存储构造，被Zookeeper形象成了树，树中的每一个节点（Node）被叫做ZNode。ZNode中保护了一个数据结构，用于记录ZNode中数据更改的版本号以及ACL（Access Control List）的变更。

有了这些数据的版本号以及其更新的Timestamp，Zookeeper就能够验证客户端申请的缓存是否非法，并协调更新。

而且，当Zookeeper的客户端执行更新或者删除操作时，都必须要带上要批改的对应数据的版本号。如果Zookeeper检测到对应的版本号不存在，则不会执行这次更新。如果非法，在ZNode中数据更新之后，其对应的版本号也会一起更新。

这套版本号的逻辑，其实很多框架都在用，例如RocketMQ中，Broker向NameServer注册的时候，也会带上这样一个版本号，叫DateVersion。

接下来咱们来具体看一下这个保护版本号相干数据的数据结构，它叫Stat Structure，其字段有：

字段释义
czxid创立该节点的zxid
mzxid最初一次批改该节点的zxid
pzxid最初一次批改该节点的子节点的zxid
ctime从以后epoch开始到该节点被创立，所距离的毫秒
mtime从以后epoch开始到该节点最初一次被编辑，所距离的毫秒
version以后节点的改变次数（也就是版本号）
cversion以后节点的子节点的改变次数
aversion以后节点的ACL改变次数
ephemeralOwner以后长期节点owner的SessionID（如果不是长期节点则为空）
dataLength以后节点的数据的长度
numChildren以后节点的子节点数量

举个例子，通过stat命令，咱们能够查看某个ZNode中Stat Structure具体的值。

对于这里的epoch、zxid是Zookeeper集群相干的货色，前面会具体的对其进行介绍。

ACL

ACL（Access Control List）用于管制ZNode的相干权限，其权限管制和Linux中的相似。Linux中权限品种分为了三种，别离是读、写、执行，别离对应的字母是r、w、x。其权限粒度也分为三种，别离是拥有者权限、群组权限、其余组权限，举个例子：

drwxr-xr-x  3 USERNAME  GROUP  1.0K  3 15 18:19 dir_name

什么叫粒度？粒度是对权限所作用的对象的分类，把下面三种粒度换个说法形容就是对用户（Owner）、用户所属的组（Group)、其余组（Other）的权限划分，这应该算是一种权限管制的规范了，典型的三段式。

Zookeeper中尽管也是三段式，然而两者对粒度的划分存在区别。Zookeeper中的三段式为Scheme、ID、Permissions，含意别离为权限机制、容许拜访的用户和具体的权限。

Scheme代表了一种权限模式，有以下5种类型：

  • world 在此中Scheme下，ID只能是anyone，代表所有人都能够拜访
  • auth 代表曾经通过了认证的用户
  • digest 应用用户名+明码来做校验。
  • ip 只容许某些特定的IP拜访ZNode
  • X509 通过客户端的证书进行认证

同时权限品种也有五种：

  • CREATE 创立节点
  • READ 获取节点或列出其子节点
  • WRITE 能设置节点的数据
  • DELETE 可能删除子节点
  • ADMIN 可能设置权限

同Linux中一样，这个权限也有缩写，举个例子：

getAcl办法用户查看对应的ZNode的权限，如图，咱们能够输入的后果呈三段式。别离是：

  • scheme 应用了world
  • id 值为anyone，代表所有用户都有权限
  • permissions 其具体的权限为cdrwa，别离是CREATE、DELETE、READ、WRITE和ADMIN的缩写

Session机制

理解了Zookeeper的Version机制，咱们能够持续摸索Zookeeper的Session机制了。

咱们晓得，Zookeeper中有4种类型的节点，别离是长久节点、长久程序节点、长期节点和长期程序节点。

在之前的文章咱们聊到过，客户端如果创立了长期节点，并在之后断开了连贯，那么所有的长期节点就都会被删除。实际上断开连接的谈话不是很准确，应该是说客户端建设连贯时的Session过期之后，其创立的所有长期节点就会被全副删除。

那么Zookeeper是怎么晓得哪些长期节点是由以后客户端创立的呢？

答案是Stat Structure中的ephemeralOwner（长期节点的Owner）字段

下面说过，如果以后是长期程序节点，那么ephemeralOwner则存储了创立该节点的Owner的SessionID，有了SessionID，天然就能和对应的客户端匹配上，当Session生效之后，能力将该客户端创立的所有长期节点全副删除。

对应的服务在创立连贯的时候，必须要提供一个带有所有服务器、端口的字符串，单个之间逗号相隔，举个例子。

127.0.0.1:3000:2181,127.0.0.1:2888,127.0.0.1:3888

Zookeeper的客户端收到这个字符串之后，会从中随机选一个服务、端口来建设连贯。如果连贯在之后断开，客户端会从字符串中抉择下一个服务器，持续尝试连贯，直到连贯胜利。

除了这种最根本的IP+端口，在Zookeeper的3.2.0之后的版本中还反对连贯串中带上门路，举个例子。

127.0.0.1:3000:2181,127.0.0.1:2888,127.0.0.1:3888/app/a

这样一来，/app/a就会被当成以后服务的根目录，在其下创立的所有的节点路经都会带上前缀/app/a。举个例子，我创立了一个节点/node_name，那其残缺的门路就会为/app/a/node_name。这个个性特地实用于多租户的环境，对于每个租户来说，都认为本人是最顶层的根目录/。

当Zookeeper的客户端和服务器都建设了连贯之后，客户端会拿到一个64位的SessionID和明码。这个明码是干什么用的呢？咱们晓得Zookeeper能够部署多个实例，如果客户端断开了连贯又和另外的Zookeeper服务器建设了连贯，那么在建设连贯使就会带上这个明码。该明码是Zookeeper的一种安全措施，所有的Zookeeper节点都能够对其进行验证。这样一来，即便连贯到了其余Zookeeper节点，Session同样无效。

Session过期有两种状况，别离是：

  • 过了指定的生效工夫
  • 指定工夫内客户端没有发送心跳

对于第一种状况，过期工夫会在Zookeeper客户端建设连贯的时候传给服务器，这个过期工夫的范畴目前只能在2倍tickTime和20倍tickTime之间。

ticktime是Zookeeper服务器的配置项，用于指定客户端向服务器发送心跳的距离，其默认值为tickTime=2000，单位为毫秒

而这套Session的过期逻辑由Zookeeper的服务器保护，一旦Session过期，服务器会立刻删除由Client创立的所有长期节点，而后告诉所有正在监听这些节点的客户端相干变更。

对于第二种状况，Zookeeper中的心跳是通过PING申请来实现的，每隔一段时间，客户端都会发送PING申请到服务器，这就是心跳的实质。心跳使服务器感知到客户端还活着，同样的让客户端也感知到和服务器的连贯依然是无效的，这个距离就是tickTime，默认为2秒。

Watch机制

理解完ZNode和Session，咱们终于能够来持续下一个要害性能Watch了，在下面的内容中也不止一次的提到监听（Watch）这个词。首先用一句话来概括其作用

给某个节点注册监听器，该节点一旦产生变更（例如更新或者删除），监听者就会收到一个Watch Event

和ZNode中有多种类型一样，Watch也有多种类型，别离是一次性Watch和永久性Watch。

  • 一次性Watch 在被触发之后，该Watch就会移除
  • 永久性Watch 在被触发之后，依然保留，能够持续监听ZNode上的变更，是Zookeeper 3.6.0版本新增的性能

一次性的Watch能够在调用getData()、getChildren()和exists()等办法时在参数中进行设置，永久性的Watch则须要调用addWatch()来实现。

并且一次性的Watch会存在问题，因为在Watch触发的事件达到客户端、再到客户端设立新的Watch，是有一个工夫距离的。而如果在这个工夫距离中产生的变更，客户端则无奈感知。

Zookeeper集群架构

ZAB协定

把后面的都铺垫好之后就能够来从整体架构的角度再深刻理解Zookeeper。Zookeeper为了保障其高可用，采纳的基于主从的读写拆散架构。

咱们晓得在相似的Redis主从架构中，节点之间是采纳的Gossip协定来进行通信的，那么在Zookeeper中通信协议是什么？

答案是ZAB（Zookeeper Atomic Broadcast）协定。

ZAB协定是一种反对解体复原的的原子播送协定，用于在Zookeeper之间传递音讯，使所有的节点都放弃同步。ZAB同时具备高性能、高可用的、容易上手、利于保护的特点，同时反对主动的故障复原。

ZAB协定将Zookeeper集群中的节点划分成了三个角色，别离是Leader、Follower和Observer，如下图：

总的来说，这套架构和Redis主从或者MySQL主从的架构相似（感兴趣的也能够去看之前的写的文章，都有聊过）

  • Redis主从
  • MySQL主从

不同点在于，通常的主从架构中存在两种角色，别离是Leader、Follower（或者是Master、Slave），但Zookeeper中多了一个Observer。

那问题来了，Observer和Follower的区别是啥呢？

实质上来说两者的性能是一样的， 都为Zookeeper提供了横向扩大的能力，使其可能扛住更多的并发。但区别在于Leader的选举过程中，Observer不参加投票选举。

程序一致性

上文提到了Zookeeper集群中是读写拆散的，只有Leader节点能解决写申请，如果Follower节点接管到了写申请，会将该申请转发给Leader节点解决，Follower节点本身是不会解决写申请的。

Leader节点接管到音讯之后，会依照申请的严格程序一一的进行解决。这是Zookeeper的一大特点，它会保障音讯的程序一致性。

举个例子，如果音讯A比音讯B先到，那么在所有的Zookeeper节点中，音讯A都会先于音讯B达到，Zookeeper会保障音讯的全局程序。

zxid

那Zookeeper是如何保障音讯的程序？答案是通过zxid。

能够简略的把zxid了解成Zookeeper中音讯的惟一ID，节点之间会通过发送Proposal（事务提议）来进行通信、数据同步，proposal中就会带上zxid和具体的数据（Message）。而zxid由两局部组成：

  • epoch 能够了解成朝代，或者说Leader迭代的版本，每个Leader的epoch都不一样
  • counter 计数器，来一条音讯就会自增

这也是惟一zxid生成算法的底层实现，因为每个Leader所应用的epoch都是惟一的，而不同的音讯在雷同的epoch中，counter的值是不同的，这样一来所有的proposal在Zookeeper集群中都有惟一的zxid。

恢复模式

失常运行的Zookeeper集群会处于播送模式。相同，如果超过半数的节点宕机，就会进入恢复模式。

什么是恢复模式？

在Zookeeper集群中，存在两种模式，别离是：

  • 恢复模式
  • 播送模式

当Zookeeper集群故障时会进入恢复模式，也叫做Leader Activation，顾名思义就是要在此阶段选举出Leader。节点之间会生成zxid和Proposal，而后互相投票。投票是要有准则的，次要有两条：

  • 选举进去的Leader的zxid肯定要是所有的Follower中最大的
  • 并且已有超过半数的Follower返回了ACK，示意认可选举进去的Leader

如果在选举的过程中产生异样，Zookeeper会间接进行新一轮的选举。如果一切顺利，Leader就会被胜利选举进去，然而此时集群还不能失常对外提供服务，因为新的Leader和Follower之间还没有进行要害的数据同步。

尔后，Leader会期待其余的Follower来连贯，而后通过Proposal向所有的Follower发送其缺失的数据。

至于怎么晓得缺失哪些数据，Proposal自身是要记录日志，通过Proposal中的zxid的低32位的Counter中的值，就能够做一个Diff

当然这里有个优化，如果缺失的数据太多，那么一条一条的发送Proposal效率太低。所以如果Leader发现缺失的数据过多就会将以后的数据打个快照，间接打包发送给Follower。

新选举进去的Leader的Epoch，会在原来的值上+1，并且将Counter重置为0。

到这你是不是认为就完了？实际上到这还是无奈失常提供服务

数据同步实现之后，Leader会发送一个NEW_LEADER的Proposal给Follower，当且仅当该Proposal被过半的Follower返回Ack之后，Leader才会Commit该NEW_LEADER Proposal，集群能力失常的进行工作。

至此，恢复模式完结，集群进入播送模式。

播送模式

在播送模式下，Leader接管到音讯之后，会向其余所有Follower发送Proposal（事务提议），Follower接管到Proposal之后会返回ACK给Leader。当Leader收到了quorums个ACK之后，以后Proposal就会提交，被利用到节点的内存中去。quorum个是多少呢？

Zookeeper官网倡议每2个Zookeeper节点中，至多有一个须要返回ACK才行，假如有N个Zookeeper节点，那计算公式应该是n/2 + 1。

这样可能不是很直观，用大白话来说就是，超过半数的Follower返回了ACK，该Proposal就可能提交，并且利用至内存中的ZNode。

Zookeeper应用2PC来保障节点之间的数据一致性（如上图），然而因为Leader须要跟所有的Follower交互，这样一来通信的开销会变得较大，Zookeeper的性能就会降落。所以为了晋升Zookeeper的性能，才从所有的Follower节点返回ACK变成了过半的Follower返回ACK即可。

好了以上就是本篇博客的全部内容了，欢送微信搜寻关注【SH的全栈笔记】，回复【队列】获取MQ学习材料，蕴含根底概念解析和RocketMQ具体的源码解析，继续更新中。

如果你感觉这篇文章对你有帮忙，还麻烦点个赞，关个注，分个享，留个言。